Re: olpc-os-builder config file format change
On Fri, Mar 2, 2012 at 6:20 PM, Daniel Drake wrote: > > Thoughts/objections? I'm not an OOB user so I will abstatin, but it sounds like a nice simplification and I am interested to hear from actual OOB users. cjl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-os-builder config file format change
+1 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
olpc-os-builder config file format change
Hi, I'm proposing the following change to olpc-os-builder configuration files for 12.1.0 and onwards: Currently, the set of modules to load is specified by a "modules" configuration variable in the [global] section. Then, settings for each module can be customised by adding a [section] for each module and specifying the options there. I propose that we simplify this: remove the "global.modules" variable, and make the presence of a section become the hint that a module is loaded. For example: [global] fedora_release=17 modules=base,xo1,yumcfg [yumcfg] add_excludes_to=fedora-rawhide Would become [global] fedora_release=17 [base] [xo1] [yumcfg] add_excludes_to=fedora-rawhide Reasoning: This is a simplification. Previously, many modules effectively had to be listed twice - once in the module list, and again to supply mandatory configuration. All too often I have seen people (including myself) adding [sections] to customise their build, but forgetting to add the module to the list. And you don't realise your error until quite a while later. Also, this simplifies the ability to pass multiple configuration files to the build system. This will become more interesting as we move towards adding build automation, where the build config file will be the same everywhere, but those who want to bolt-on automatic build publishing at the end will supply an additional config file (loading futher modules) specifying addresses to push the build to, etc. Thoughts/objections? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 development build 29 for XO-1.75
On 02.03.2012, at 18:49, Martin Langhoff wrote: > Upgrade online with: > > olpc-update 11.3.1_xo1.75-28 That should be olpc-update 11.3.1_xo1.75-29 and yes it works (from os28) - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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.0 -0500 +++ os29/xo1.75/os29.packages.txt 2012-03-02 12:07:44.0 -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 -- mar...@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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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!
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea: set a niceness value under which a process won't awaken suspended CPU
On Mar 2, 2012 11:06 AM, "Lennert Buytenhek" 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@lists.laptop.org
http://lists.laptop.org/listinfo/devel
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.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: idea: set a niceness value under which a process won't awaken suspended CPU
On Mar 2, 2012 10:37 AM, "Lennert Buytenhek" 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@lists.laptop.org
http://lists.laptop.org/listinfo/devel
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.l9o9c1k2026...@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
>
> 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@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
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" 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.l9o9c1k2026...@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 > > 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@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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.l9o9c1k2026...@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 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@lists.laptop.org http://lists.laptop.org/listinfo/devel
