Jerry Vonau | 1 Mar 15:07 2012
Picon

Re: [Dextrose] [PATCH dextrose 1/3] Fix root file system type in /etc/fstab

On Tue, 2012-02-28 at 20:10 +0100, Sascha Silbe wrote:
> Since 41b79e7aaa17e5f3003fd5a72f8bfc20b2fc4f1c the root file system is
> ext4, but we were still telling kickstart it's ext3. This caused an
> incorrect fstab to be written, so booting using regular (i.e. Fedora)
> initramfs failed.
> 
> Signed-off-by: Sascha Silbe <silbe <at> activitycentral.com>
> ---
>  modules/base/ksmain.10.core.inc |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/modules/base/ksmain.10.core.inc b/modules/base/ksmain.10.core.inc
> index 0e7c39e..cc3f2f7 100644
> --- a/modules/base/ksmain.10.core.inc
> +++ b/modules/base/ksmain.10.core.inc
>  <at>  <at>  -4,6 +4,6  <at>  <at>  auth --useshadow --enablemd5
>  selinux --disabled
>  firewall --disabled
>  xconfig --startxonboot
> -part / --size 4096 --fstype=ext3
> +part / --size 4096 --fstype=ext4
>  services --enabled=avahi-daemon,crond,messagebus,NetworkManager --disabled=dnsmasq,ip6tables,iptables,mdmonitor,netfs,network,sshd
>  

http://dev.laptop.org/ticket/11558

Jerry
John Gilmore | 2 Mar 09:38 2012

idea: set a niceness value under which a process won't awaken suspended CPU

Here's a power-saving idea that's been marinating since 2007 (in an
obscure corner of my mail queue).  When I reviewed it today I didn't
see anything too wrong with it.

	John

Message-Id: <200710240912.l9O9C1k2026420 <at> new.toad.com>
To: gnu
Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU
Date: Wed, 24 Oct 2007 02:12:01 -0700
From: John Gilmore <gnu <at> toad.com>

An easy lever for CPU consumption management (power mgmt) would be to
define a set of user processes that won't be scheduled in a
power-suspended system.  They won't wake the CPU even if their timer
goes off, their packet arrives, or their fairy godmother calls.  But
if something else wakes the CPU, and it's going to stay running a bit
while some higher priority process is waiting for flash or packets or
something, these processes can run in the background.

My idea is to tie this to "nice".  So if you "nice -20", it puts you into
this range.  Say everything below -15, which lets you set a few priorities
among the low priority background stuff.

So if you nice things all the way down, they run when the CPU is powered,
in the cracks when there's nothing else to do, but they don't cause the CPU
to wake up to service them if nothing else is going on.

For example, code that polls and updates the battery status once a
minute in HAL.  Or a system activity monitor that shows CPU state
(Continue reading)

Jon Nettleton | 2 Mar 10:12 2012
Picon

Re: idea: set a niceness value under which a process won't awaken suspended CPU

Although the idea sounds good, the mechanism of using nice is very 2007 :-)  This should be accomplished by putting this type of process in a specific cgroup.  We can then use the cgroup freezer to freeze all tasks in that group, and thaw it when we see fit.

I used a similar mechanism to fix the problem where my wife would have all sorts of flash things running in different tabs of her web browser, when I was switched over to my user profile on the netbook.  I added some hooks into policy kit to thaw the background users cgroup and unthaw the logged in user.  Really I could have just limited the amount of processor resources they had access to, but why waste the battery?

Other than that I think this could be a very good thing.  I also think this would be a good way to control things that we only want to run when plugged in.  No reason to run some of those cpu intensive cron jobs when running on battery.

-Jon

On Mar 2, 2012 9:44 AM, "John Gilmore" <gnu <at> toad.com> wrote:
>
> Here's a power-saving idea that's been marinating since 2007 (in an
> obscure corner of my mail queue).  When I reviewed it today I didn't
> see anything too wrong with it.
>
>        John
>
> Message-Id: <200710240912.l9O9C1k2026420 <at> new.toad.com>
> To: gnu
> Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU
> Date: Wed, 24 Oct 2007 02:12:01 -0700
> From: John Gilmore <gnu <at> toad.com>
>
> An easy lever for CPU consumption management (power mgmt) would be to
> define a set of user processes that won't be scheduled in a
> power-suspended system.  They won't wake the CPU even if their timer
> goes off, their packet arrives, or their fairy godmother calls.  But
> if something else wakes the CPU, and it's going to stay running a bit
> while some higher priority process is waiting for flash or packets or
> something, these processes can run in the background.
>
> My idea is to tie this to "nice".  So if you "nice -20", it puts you into
> this range.  Say everything below -15, which lets you set a few priorities
> among the low priority background stuff.
>
> So if you nice things all the way down, they run when the CPU is powered,
> in the cracks when there's nothing else to do, but they don't cause the CPU
> to wake up to service them if nothing else is going on.
>
> For example, code that polls and updates the battery status once a
> minute in HAL.  Or a system activity monitor that shows CPU state
> graphs or how many MHz we're running.  Or an RSS feed reader.  Or the
> thing that clears out Mozilla's cache.  Or the incremental backup
> daemon that copies the machine's state to the school server.  (If that
> ran with scavenged electricity, cool!  It can raise its priority once
> a day or so, to make sure that a backup gets done one way or another.)
>
> The GUI could have a way to throw a process into this state or out of it.
> E.g. push your mail reader there, polling every once in a while for email,
> opportunistically.
>
>        John
>
> ------- End of Forwarded Message
>
> _______________________________________________
> Devel mailing list
> Devel <at> lists.laptop.org
> http://lists.laptop.org/listinfo/devel

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
Lennert Buytenhek | 2 Mar 10:36 2012

Re: idea: set a niceness value under which a process won't awaken suspended CPU

One problem you can get into with this scheme is a kind of priority
inversion.  If the low priority process does:

	fd = open("/foo/bar", O_RDWR);
	flock(fd, LOCK_EX);

and the high priority process then also does:

	fd = open("/foo/bar", O_RDWR);
	flock(fd, LOCK_EX);

and the low priority process then does:

	sleep(1);
	flock(fd, LOCK_UN);

and the system then goes into suspend, you'll not wake up again
after that second expires, and you might not wake up again soon
at all.  The low priority process doesn't even have to sleep
explicitly, if it takes a page fault you get basically the same
thing.

Nice levels don't seem the right method of controlling which tasks
get to wake up the CPU and which don't, but note that a simple
per-process "will/won't wake up the CPU" flag won't avoid the above
scenario either.

On Fri, Mar 02, 2012 at 12:38:40AM -0800, John Gilmore wrote:

> Here's a power-saving idea that's been marinating since 2007 (in an
> obscure corner of my mail queue).  When I reviewed it today I didn't
> see anything too wrong with it.
> 
> 	John
> 
> Message-Id: <200710240912.l9O9C1k2026420 <at> new.toad.com>
> To: gnu
> Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU
> Date: Wed, 24 Oct 2007 02:12:01 -0700
> From: John Gilmore <gnu <at> toad.com>
> 
> An easy lever for CPU consumption management (power mgmt) would be to
> define a set of user processes that won't be scheduled in a
> power-suspended system.  They won't wake the CPU even if their timer
> goes off, their packet arrives, or their fairy godmother calls.  But
> if something else wakes the CPU, and it's going to stay running a bit
> while some higher priority process is waiting for flash or packets or
> something, these processes can run in the background.
> 
> My idea is to tie this to "nice".  So if you "nice -20", it puts you into
> this range.  Say everything below -15, which lets you set a few priorities
> among the low priority background stuff.
> 
> So if you nice things all the way down, they run when the CPU is powered,
> in the cracks when there's nothing else to do, but they don't cause the CPU
> to wake up to service them if nothing else is going on.
> 
> For example, code that polls and updates the battery status once a
> minute in HAL.  Or a system activity monitor that shows CPU state
> graphs or how many MHz we're running.  Or an RSS feed reader.  Or the
> thing that clears out Mozilla's cache.  Or the incremental backup
> daemon that copies the machine's state to the school server.  (If that
> ran with scavenged electricity, cool!  It can raise its priority once
> a day or so, to make sure that a backup gets done one way or another.)
> 
> The GUI could have a way to throw a process into this state or out of it.
> E.g. push your mail reader there, polling every once in a while for email,
> opportunistically.
> 
> 	John
> 
> ------- End of Forwarded Message
> 
> _______________________________________________
> Devel mailing list
> Devel <at> lists.laptop.org
> http://lists.laptop.org/listinfo/devel
Jon Nettleton | 2 Mar 10:50 2012
Picon

Re: idea: set a niceness value under which a process won't awaken suspended CPU


On Mar 2, 2012 10:37 AM, "Lennert Buytenhek" <buytenh <at> wantstofly.org> wrote:
>
> One problem you can get into with this scheme is a kind of priority
> inversion.  If the low priority process does:
>
>        fd = open("/foo/bar", O_RDWR);
>        flock(fd, LOCK_EX);
>
> and the high priority process then also does:
>
>        fd = open("/foo/bar", O_RDWR);
>        flock(fd, LOCK_EX);
>
> and the low priority process then does:
>
>        sleep(1);
>        flock(fd, LOCK_UN);
>
> and the system then goes into suspend, you'll not wake up again
> after that second expires, and you might not wake up again soon
> at all.  The low priority process doesn't even have to sleep
> explicitly, if it takes a page fault you get basically the same
> thing.

I believe the cgroup method will catch this though.  I would have to double check, but I think that the cgroup becomes partially frozen returning EBUSY until all the processes can properly be frozen.  At that time I believe it is up to userspace to thaw, or refreeze the group, unless the blocking process ends in which case the entire cgroup is set to the frozen state.

-Jon

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
Lennert Buytenhek | 2 Mar 11:06 2012

Re: idea: set a niceness value under which a process won't awaken suspended CPU

On Fri, Mar 02, 2012 at 01:50:16AM -0800, Jon Nettleton wrote:

> > One problem you can get into with this scheme is a kind of priority
> > inversion.  If the low priority process does:
> >
> >        fd = open("/foo/bar", O_RDWR);
> >        flock(fd, LOCK_EX);
> >
> > and the high priority process then also does:
> >
> >        fd = open("/foo/bar", O_RDWR);
> >        flock(fd, LOCK_EX);
> >
> > and the low priority process then does:
> >
> >        sleep(1);
> >        flock(fd, LOCK_UN);
> >
> > and the system then goes into suspend, you'll not wake up again
> > after that second expires, and you might not wake up again soon
> > at all.  The low priority process doesn't even have to sleep
> > explicitly, if it takes a page fault you get basically the same
> > thing.
> 
> I believe the cgroup method will catch this though.  I would have
> to double check, but I think that the cgroup becomes partially
> frozen returning EBUSY until all the processes can properly be
> frozen.  At that time I believe it is up to userspace to thaw, or
> refreeze the group, unless the blocking process ends in which case
> the entire cgroup is set to the frozen state.

You can still suffer from priority inversion if you freeze a cgroup
with a low priority process in it that holds a resource that another
high priority process needs.

You indeed can't suffer from priority inversion between processes in
the same cgroup if you are going to freeze all of them, but then you
don't care about CPU wakeups for the high priority process either.

I guess that what I don't see yet is how you would use cgroups to
implement the goals of John's scheme.
Jon Nettleton | 2 Mar 11:19 2012
Picon

Re: idea: set a niceness value under which a process won't awaken suspended CPU


On Mar 2, 2012 11:06 AM, "Lennert Buytenhek" <buytenh <at> wantstofly.org> wrote:
>
> On Fri, Mar 02, 2012 at 01:50:16AM -0800, Jon Nettleton wrote:
>
> > > One problem you can get into with this scheme is a kind of priority
> > > inversion.  If the low priority process does:
> > >
> > >        fd = open("/foo/bar", O_RDWR);
> > >        flock(fd, LOCK_EX);
> > >
> > > and the high priority process then also does:
> > >
> > >        fd = open("/foo/bar", O_RDWR);
> > >        flock(fd, LOCK_EX);
> > >
> > > and the low priority process then does:
> > >
> > >        sleep(1);
> > >        flock(fd, LOCK_UN);
> > >
> > > and the system then goes into suspend, you'll not wake up again
> > > after that second expires, and you might not wake up again soon
> > > at all.  The low priority process doesn't even have to sleep
> > > explicitly, if it takes a page fault you get basically the same
> > > thing.
> >
> > I believe the cgroup method will catch this though.  I would have
> > to double check, but I think that the cgroup becomes partially
> > frozen returning EBUSY until all the processes can properly be
> > frozen.  At that time I believe it is up to userspace to thaw, or
> > refreeze the group, unless the blocking process ends in which case
> > the entire cgroup is set to the frozen state.
>
> You can still suffer from priority inversion if you freeze a cgroup
> with a low priority process in it that holds a resource that another
> high priority process needs.
>
> You indeed can't suffer from priority inversion between processes in
> the same cgroup if you are going to freeze all of them, but then you
> don't care about CPU wakeups for the high priority process either.
>
> I guess that what I don't see yet is how you would use cgroups to
> implement the goals of John's scheme.

The cgroup would be the method to organize the processes that you don't want running all  the time, but only when a higher priority processes has already woken the cpu and is doing significant work.  If we put all these "background" processes in a special cgroup, we can freeze their activity before suspend, or any other arbitrary time at that point.  Then it would be up to a process scheduler, or a userspace daemon to decided when we would want to thaw this group because our system will already be up and doing work.  We can also put a lower priority on that cgroup as to not steal cpu cycles from the process that caused the cpu/system to wakeup to do work.

Am I misunderstanding the concept proposed?

-Jon

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
Simon Schampijer | 2 Mar 13:09 2012
Picon

ConsoleKit Removal

Hi,

Fedora is switching away from ConsoleKit and is using systemd instead 
[1]. Looks like olpc-utils needs to be updated to reflect that. We seem 
to open/close a ConsoleKit session in olpc-dm.c.

Regards,
    Simon

[1] http://fedoraproject.org/wiki/Features/ckremoval
[2] http://dev.laptop.org/git/projects/olpc-utils/tree/src/olpc-dm.c#n229
Lennert Buytenhek | 2 Mar 14:38 2012

Re: idea: set a niceness value under which a process won't awaken suspended CPU

On Fri, Mar 02, 2012 at 02:19:43AM -0800, Jon Nettleton wrote:

> > > > One problem you can get into with this scheme is a kind of priority
> > > > inversion.  If the low priority process does:
> > > >
> > > >        fd = open("/foo/bar", O_RDWR);
> > > >        flock(fd, LOCK_EX);
> > > >
> > > > and the high priority process then also does:
> > > >
> > > >        fd = open("/foo/bar", O_RDWR);
> > > >        flock(fd, LOCK_EX);
> > > >
> > > > and the low priority process then does:
> > > >
> > > >        sleep(1);
> > > >        flock(fd, LOCK_UN);
> > > >
> > > > and the system then goes into suspend, you'll not wake up again
> > > > after that second expires, and you might not wake up again soon
> > > > at all.  The low priority process doesn't even have to sleep
> > > > explicitly, if it takes a page fault you get basically the same
> > > > thing.
> > >
> > > I believe the cgroup method will catch this though.  I would have
> > > to double check, but I think that the cgroup becomes partially
> > > frozen returning EBUSY until all the processes can properly be
> > > frozen.  At that time I believe it is up to userspace to thaw, or
> > > refreeze the group, unless the blocking process ends in which case
> > > the entire cgroup is set to the frozen state.
> >
> > You can still suffer from priority inversion if you freeze a cgroup
> > with a low priority process in it that holds a resource that another
> > high priority process needs.
> >
> > You indeed can't suffer from priority inversion between processes in
> > the same cgroup if you are going to freeze all of them, but then you
> > don't care about CPU wakeups for the high priority process either.
> >
> > I guess that what I don't see yet is how you would use cgroups to
> > implement the goals of John's scheme.
> 
> The cgroup would be the method to organize the processes that you don't
> want running all  the time, but only when a higher priority processes has
> already woken the cpu and is doing significant work.  If we put all these
> "background" processes in a special cgroup, we can freeze their activity
> before suspend, or any other arbitrary time at that point.  Then it would
> be up to a process scheduler, or a userspace daemon to decided when we
> would want to thaw this group because our system will already be up and
> doing work.  We can also put a lower priority on that cgroup as to not
> steal cpu cycles from the process that caused the cpu/system to wakeup to
> do work.
> 
> Am I misunderstanding the concept proposed?

If you suspend the whole cgroup whenever the system suspends, and thaw
it when the system resumes, then yes, that'll give more or less the
same behavior as John's proposal[*].  It doesn't change the priority
inversion scenario, though.

[*] Not entirely the same, as he seems to be talking about reliable
    CPU wakeup filtering as well, which just isn't possible in all
    cases, e.g. when a packet arrives, the NIC won't know whether
    that packet is destined for a high or low priority process, so
    you can't make the CPU wakeup decision in the NIC, and the CPU
    won't be able to make the decision either, as it would have to
    wake up to inspect the packet to do that, which is what you were
    trying to avoid in the first place!
Martin Langhoff | 2 Mar 18:49 2012

11.3.1 development build 29 for XO-1.75

This build brings in OFW improvements, audio fixes, olpc-update,
ds-backup, powerd and new power logging scripts.

It should be updatable via olpc-update -- try the cmdline below.

Notes:

 - In normal use, the laptop sometimes hangs when idle; very likely
when it is suspending or resuming; please help us diagnose this
further at #11600 and #11658

 - Record Activity will sometimes hang - #11657

 - The getty on the serial port is _disabled_ by default now (that's
the workaround). It gets enabled when you hold the "check" game key
during boot (for verbose boot).

Upgrade online with:

   olpc-update 11.3.1_xo1.75-28

Download from:

  http://build.laptop.org/11.3.1/os29/

Fixes (please help us confirm):

#11664 olpc-update-query has a hardcoded /ofw path
#11665 olpc-update needs to learn about devicetree
#11667 Teach ds-backup about devicetree
#11623 Add olpc-pwr-log Ver 2.1.0 to build

Changes:

--- os28/xo1.75/os28.packages.txt	2012-02-18 08:55:05.000000000 -0500
+++ os29/xo1.75/os29.packages.txt	2012-03-02 12:07:44.000000000 -0500
-ds-backup-client-0.11.1.g71d2f16-1.olpc3.noarch
+ds-backup-client-0.12-1.fc14.noarch
-kernel-3.0.19_xo1.75-20120214.2038.olpc.6ac727b.armv7l
+kernel-3.0.19_xo1.75-20120223.0009.olpc.f11c4ee.armv7l
-olpc-firmware-q4d03-1.unsigned.noarch
+olpc-firmware-q4d04-1.unsigned.noarch
-olpc-powerd-44-1.fc14.armv5tel
-olpc-powerd-dbus-44-1.fc14.armv5tel
+olpc-powerd-45-1.fc14.armv5tel
+olpc-powerd-dbus-45-1.fc14.armv5tel
-olpc-update-2.23-1.fc14.noarch
-olpc-utils-1.3.12-1.fc14.armv5tel
+olpc-update-2.24-1.fc14.noarch
+olpc-utils-1.3.13-1.fc14.armv5tel

Kernel changelog
Paul Fox (3):
      raydium_ts:  general cleanup
      raydium_ts: put the touchscreen to sleep during suspend when possible
      olpc-ec: (re)disable EC SSP interrupts across suspend

Saadia Baloch (2):
      mmp2-i2s.c: Remove symmetric_rates restriction
      mmp2-pcm.c: Protect audio DMA from interrupts

OFW Q4D04 changelog
- FAT32 filesystem compatibility fix,
- fs-update and fs-verify refinements,
- null-fsdisk works again,
- terminal emulator fixes,
- avoid black text on black background on Linux console or xterm,

cheers,

m
--
 martin <at> laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Gmane