Re: LZO support (was: [Re: low power actions?])
On Jul 14 2008, at 12:07, Erik Garrison was caught saying: > There is an existing ticket to address this issue > (http://dev.laptop.org/ticket/2072). This ticket suggests that we could > add LZO support to OFW in order to implement LZO-compressed data nodes > in the filesystem. > > In this scheme OFW would require LZO support to boot a kernel which > resides on an LZO-compressed fs. But an alternative is to implement a > partitioning scheme in which user data resides on a LZO-compressed > partition and the system data resides on a zlib-compressed partition. > This would provide us with good compression for system components > (saving space) but would also allow users to write data much more > quickly. That said, implementing LZO compression across the entire > system might improve system responsiveness by a noticeable margin, so it > might be worthwhile. Testing is required. Partitioning is already on our roadmap, so if we just put /boot and other OFW needed data in a non-LZO partition, we can live w/o needing to update OFW to handle LZO. ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
LZO support (was: [Re: low power actions?])
On Fri, Jul 11, 2008 at 06:33:41PM +0100, Gary C Martin wrote: > > One concern I have with auto saving state before powering off is the > potential corruption of journal data. How robust is the Journal if > power off happens half way through an ongoing auto state save – do you > loose both the new journal entry and the original entry you had > resumed from (partially overwritten)? > > The worst case just now seems to be EToys, it's really great for > tinkering, but creating even simple scripts seems to require a massive > amount of time to save (example 5+min!! to close & save a script with > five polygon space invaders with 2 frames of animation and a few lines > of movement code). Add to that that EToys seems to be almost as power > intensive as video recording (my impression only, I've not power > tested). I find I'm the habit of plugging into mains before I try and > close an EToys instance I've made more than a few modifications to. > Based on some very provisional testing, I believe that the extremely long save times we're seeing in EToys are at least partly related to our use of zlib compression for data nodes in the filesystem. We could switch to LZO compression for a 500% speedup in compression (write), a 50% speedup in decompression (read), and a slight (but significant) decrease in compression ratio. While working with Record I noticed that we cannot write very high resolution video (>320x240 @ 10fps) to the filesystem because of this issue. It would help to know what other applications are suffering because of poor fs write speed. There is an existing ticket to address this issue (http://dev.laptop.org/ticket/2072). This ticket suggests that we could add LZO support to OFW in order to implement LZO-compressed data nodes in the filesystem. In this scheme OFW would require LZO support to boot a kernel which resides on an LZO-compressed fs. But an alternative is to implement a partitioning scheme in which user data resides on a LZO-compressed partition and the system data resides on a zlib-compressed partition. This would provide us with good compression for system components (saving space) but would also allow users to write data much more quickly. That said, implementing LZO compression across the entire system might improve system responsiveness by a noticeable margin, so it might be worthwhile. Testing is required. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: low power actions?
On Fri, Jul 11, 2008 at 7:33 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > > One concern I have with auto saving state before powering off is the > potential corruption of journal data. How robust is the Journal if > power off happens half way through an ongoing auto state save – do you > loose both the new journal entry and the original entry you had > resumed from (partially overwritten)? It should be pretty robust, AFAIK, but we should do some stress testing, any takers? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: low power actions?
chris wrote: > Hi, > >> What would it take to put in a journaling filesystem? > > The "j" in "jffs2" stands for "journalling". to expand -- i believe the shutdown-inspired corruption people are worried about is not filesystem corruption, but application corruption -- if the activity doesn't completely write its state before the system is shut down, no amount of filesystem protection will help. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: low power actions?
Hi, > What would it take to put in a journaling filesystem? The "j" in "jffs2" stands for "journalling". - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: low power actions?
What would it take to put in a journaling filesystem? On Fri, Jul 11, 2008 at 10:49 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 1:33 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: >> One concern I have with auto saving state before powering off is the >> potential corruption of journal data. How robust is the Journal if >> power off happens half way through an ongoing auto state save – do you >> loose both the new journal entry and the original entry you had >> resumed from (partially overwritten)? > > Disclaimer: I'm not a technical expert on the DS, so others more > familiar should probably correct me if I make claims below that are > false. > > This is yet another problem that can be bypassed with the "new DS". > In one of our past meetings, we laid out requirements for the process > by which activities save their state, and it included a means for > activities to check in temporary saves if they wished to, optionally > passing a flag to tell the Journal to actually create a new entry. > This system was in place such that, if the Journal detected that a > given activity crashed, it could automatically make a new Journal > entry based on the last temporary save, as a form of auto-recovery. > This approach could similarly be used after a power failure. > > Additionally, in the worst case a corrupt entry might wind up in the > Journal, but that shouldn't be a problem because, at present, copies > are stored so there is no loss of data, and in the future we'll have > versions, and only one version of many would be corrupt. It should > never be the case that the entry that was opened gets corrupted. > Ideally the Journal would be able to recognize when a save transaction > doesn't finish and either replace it with the most recent temporary > state or remove the entry compeletely. > > - Eben > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: low power actions?
On Fri, Jul 11, 2008 at 1:33 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > One concern I have with auto saving state before powering off is the > potential corruption of journal data. How robust is the Journal if > power off happens half way through an ongoing auto state save – do you > loose both the new journal entry and the original entry you had > resumed from (partially overwritten)? Disclaimer: I'm not a technical expert on the DS, so others more familiar should probably correct me if I make claims below that are false. This is yet another problem that can be bypassed with the "new DS". In one of our past meetings, we laid out requirements for the process by which activities save their state, and it included a means for activities to check in temporary saves if they wished to, optionally passing a flag to tell the Journal to actually create a new entry. This system was in place such that, if the Journal detected that a given activity crashed, it could automatically make a new Journal entry based on the last temporary save, as a form of auto-recovery. This approach could similarly be used after a power failure. Additionally, in the worst case a corrupt entry might wind up in the Journal, but that shouldn't be a problem because, at present, copies are stored so there is no loss of data, and in the future we'll have versions, and only one version of many would be corrupt. It should never be the case that the entry that was opened gets corrupted. Ideally the Journal would be able to recognize when a save transaction doesn't finish and either replace it with the most recent temporary state or remove the entry compeletely. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: low power actions?
On 11 Jul 2008, at 16:20, Chris Ball wrote:
> Hi,
>
>> my interest was piqued by someone on irc asking about automatic
>> clean shutdowns for low power. i was wondering whether we do that,
>> and whether we do earlier user warnings ("your battery should be
>> charged now in order to keep it healthy"), or perhaps forced
>> suspends.
>
> Well, we shut off automatically in order to keep the battery healthy,
> so there's no user involvement needed there.
>
> I don't currently do anything in userspace on low power, but the
> feature
> of "shutting down should save state" is targeted at 8.2, and I think
> the
> Sugar side is done; I just need a way to trigger the state saving from
> OHM when power is low. I've added the request to #6014.
One concern I have with auto saving state before powering off is the
potential corruption of journal data. How robust is the Journal if
power off happens half way through an ongoing auto state save – do you
loose both the new journal entry and the original entry you had
resumed from (partially overwritten)?
The worst case just now seems to be EToys, it's really great for
tinkering, but creating even simple scripts seems to require a massive
amount of time to save (example 5+min!! to close & save a script with
five polygon space invaders with 2 frames of animation and a few lines
of movement code). Add to that that EToys seems to be almost as power
intensive as video recording (my impression only, I've not power
tested). I find I'm the habit of plugging into mains before I try and
close an EToys instance I've made more than a few modifications to.
--Gary
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: low power actions?
chris wrote:
> Hi,
>
>> my interest was piqued by someone on irc asking about automatic
>> clean shutdowns for low power. i was wondering whether we do that,
>> and whether we do earlier user warnings ("your battery should be
>> charged now in order to keep it healthy"), or perhaps forced
>> suspends.
>
> Well, we shut off automatically in order to keep the battery healthy,
> so there's no user involvement needed there.
to clarify: "shut off automatically" == "clean shutdown"?
> I don't currently do anything in userspace on low power, but the feature
> of "shutting down should save state" is targeted at 8.2, and I think the
> Sugar side is done; I just need a way to trigger the state saving from
> OHM when power is low. I've added the request to #6014.
heh. whatever happened to SIGTERM. :-) (only half joking)
paul
=-
paul fox, [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: low power actions?
There are 2 or 3 things we want to do in userspace as the battery gets
low, neither of which have been implemented yet.
1. When the battery begins to get low (15%?) we can use the new (and,
actually, not quite finished) notification system to alert the user
that the battery is low and that they might want to consider finding a
power source. This notification would appear in the lower-right
corner (the "device" corner), and be mostly unobtrusive. Optionally,
we could have this notification occur several times as the battery
gets lower, but I don't want to overdo it.
2. When the battery gets critically low (5%?) and a shutdown is
imminent, we should display a modal alert which prevents further
interaction with the system, and strongly suggests (probably with a
nice graphic) that the machine be attached to power in order to
continue using it. Once power is reconnected, the alert will
automatically be dismissed.
3. When the system gives up and resorts to a force shutdown/suspend,
we could change the content of the modal alert to indicate that the
state of open activities are being kept in the Journal, and the
machine is shutting down/suspending.
We could do a rough pass at (1), though the notification system is
fleshed out as much as it needs to be. We could likely do (2,3) now.
- Eben
On Fri, Jul 11, 2008 at 11:20 AM, Chris Ball <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > my interest was piqued by someone on irc asking about automatic
> > clean shutdowns for low power. i was wondering whether we do that,
> > and whether we do earlier user warnings ("your battery should be
> > charged now in order to keep it healthy"), or perhaps forced
> > suspends.
>
> Well, we shut off automatically in order to keep the battery healthy,
> so there's no user involvement needed there.
>
> I don't currently do anything in userspace on low power, but the feature
> of "shutting down should save state" is targeted at 8.2, and I think the
> Sugar side is done; I just need a way to trigger the state saving from
> OHM when power is low. I've added the request to #6014.
>
> Thanks,
>
> - Chris.
> --
> Chris Ball <[EMAIL PROTECTED]>
> ___
> 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: low power actions?
Hi,
> my interest was piqued by someone on irc asking about automatic
> clean shutdowns for low power. i was wondering whether we do that,
> and whether we do earlier user warnings ("your battery should be
> charged now in order to keep it healthy"), or perhaps forced
> suspends.
Well, we shut off automatically in order to keep the battery healthy,
so there's no user involvement needed there.
I don't currently do anything in userspace on low power, but the feature
of "shutting down should save state" is targeted at 8.2, and I think the
Sugar side is done; I just need a way to trigger the state saving from
OHM when power is low. I've added the request to #6014.
Thanks,
- Chris.
--
Chris Ball <[EMAIL PROTECTED]>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: low power actions?
smith wrote:
> [EMAIL PROTECTED] wrote:
> > a thread on irc from last evening prompts me to ask: where can i
> > find a description of how the laptop behaves (LED behavior, powerdown
> > behavior, etc) as the battery gets low?
>
> EC wise: The EC turns on the red led when it thinks the battery is
> empty. This is by an SOC % dropping < 15%. If the battery voltage
> depletes further to a level where cell damage will occur it turns the
> system off.
>
my interest was piqued by someone on irc asking about automatic
clean shutdowns for low power. i was wondering whether we do
that, and whether we do earlier user warnings ("your battery
should be charged now in order to keep it healthy"), or perhaps
forced suspends.
paul
=-
paul fox, [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: low power actions?
[EMAIL PROTECTED] wrote: > a thread on irc from last evening prompts me to ask: where can i > find a description of how the laptop behaves (LED behavior, powerdown > behavior, etc) as the battery gets low? EC wise: The EC turns on the red led when it thinks the battery is empty. This is by an SOC % dropping < 15%. If the battery voltage depletes further to a level where cell damage will occur it turns the system off. Other than that I don't think anything else changes. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
low power actions?
a thread on irc from last evening prompts me to ask: where can i find a description of how the laptop behaves (LED behavior, powerdown behavior, etc) as the battery gets low? brief searching led me to http://wiki.laptop.org/go/Power_Management#Power_Management_Scenarios but this scenario (battery getting low/critical) doesn't seem to be covered. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
