CE Linux Forum PM Requierments WiKi is available for review and comment.

CE Linux Forum PM Requierments WiKi is available for review and comment.

[Gross, Mark]

[-- Attachment #1.1: Type: text/plain, Size: 819 bytes --]

Please visit
http://tree.celinuxforum.org/CelfPubWiki/CELFPmRequirements2006

 

This is a simple draft requirements document listing the candidate items
that may be included in a final PM requirements PDF document.  The CELF
PM Working group is trying to define a set of requirements from which
some projects and investigations will be derived.  We very much welcome
input and ideas from the larger development community.

 

I'm hoping to derive a more formal requirements document for CELF out of
this WiKi for use in defining some projects this April.

 

All public comments, private comments, and WiKi edits are welcome.

 

Thanks,

 

--mgross

Intel Open Source Technology Center

(503) 677-4628

(503)-712-6227

ms: JF1-235

2111 NW 25th Ave

Hillsboro, OR 97124

 


[-- Attachment #1.2: Type: text/html, Size: 7225 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: CE Linux Forum PM Requierments WiKi is available for review and comment.

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

Hi!

Please do not post html to the lists.

> Please visit
> http://tree.celinuxforum.org/CelfPubWiki/CELFPmRequirements2006
> 
>  
> 
> This is a simple draft requirements document listing the candidate items
> that may be included in a final PM requirements PDF document.  The CELF
> PM Working group is trying to define a set of requirements from which
> some projects and investigations will be derived.  We very much welcome
> input and ideas from the larger development community.
... 
> All public comments, private comments, and WiKi edits are welcome.


4. device power management seems to be missing. What is "OS
throttling"? 

You seem to want to do device throttling. Device powering off should
be there, too.

5.1 you seem to dislike ACPI, but I guess you should add proposal to
new /sys interface.

6.1 "UI responsiveness governor"? That sounds more like usermode
governor, and we have that one already. Thermal governor should not be
needed, it should be included in *every* governor.

7.1 if your hardware can damage itself or hurt user *FIX YOUR
HARDWARE*! Will you argue that overcharging li-ion to explosion is also ok?

9 uswsusp should be able to suspend-to-flash.

9.2 yep, I'm telling you this is easy to do. No need to change kernel,
even, just needs recent -mm.

								Pavel
-- 
Thanks, Sharp!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: CE Linux Forum PM Requierments WiKi is available for review and comment.

[Gross, Mark]

[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]

Thanks for taking the time to look at it and provide a response.

>-----Original Message-----
>From: Pavel Machek [mailto:pavel@ucw.cz]
>Sent: Sunday, March 19, 2006 11:22 AM
>To: Gross, Mark
>Cc: linux-pm@osdl.org; mli_tech@groups.osdl.org; celinux-
>dev@tree.celinuxforum.org; PMWG@LIST.CELINUXFORUM.ORG
>Subject: Re: [linux-pm] CE Linux Forum PM Requierments WiKi is
available
>for review and comment.
>
>Hi!
>
>Please do not post html to the lists.

Yeah, I know that's why I re-sent a non-HTML version.  
My bad....

>
>> Please visit
>> http://tree.celinuxforum.org/CelfPubWiki/CELFPmRequirements2006
>>
>>
>>
>> This is a simple draft requirements document listing the candidate
items
>> that may be included in a final PM requirements PDF document.  The
CELF
>> PM Working group is trying to define a set of requirements from which
>> some projects and investigations will be derived.  We very much
welcome
>> input and ideas from the larger development community.
>...
>> All public comments, private comments, and WiKi edits are welcome.
>
>
>4. device power management seems to be missing. What is "OS
>throttling"?
>

I'll add some stuff on device power management.  

OS throttling is the pacing of work the OS is allowed to do to maintain
some power or thermal budget constraints.

>You seem to want to do device throttling. Device powering off should
>be there, too.

Yes.  I'll add device power control to the list.

>
>5.1 you seem to dislike ACPI, but I guess you should add proposal to
>new /sys interface.
>

I LOVE ACPI!  Doesn't everyone? :)

However; many CE platforms don't have the platform FW / BIOS
infrastructure needed to make ACPI operate.  ACPI is just not an option
for most CE platforms.

Yes new /sys interfaces will likely be needed.  We haven't drilled down
on what they should be just yet.  

>6.1 "UI responsiveness governor"? That sounds more like usermode
>governor, and we have that one already. Thermal governor should not be
>needed, it should be included in *every* governor.
>

Actually to do a good job at this you need to know the latency from
interrupt to scheduling the process responding to the event.  You can't
do this type of control from the user mode governor without some kernel
support.


>7.1 if your hardware can damage itself or hurt user *FIX YOUR
>HARDWARE*! Will you argue that overcharging li-ion to explosion is also
ok?
>

Having your hardware catch on fire or exploding is not ok.  I'll
re-write this a bit to avoid the inference of buggy hardware.   The
point is that software support is needed to do a good job for some of
these applications.

However; Having the OS help avoid deep discharging your cell phone or
I-Pod battery because of some bug would not be unreasonable.

Neither is having OS support running on hardware that is built without
active cooling that avoids the HW doing an emergency power off and
loosing the users data.

>9 uswsusp should be able to suspend-to-flash.
>
>9.2 yep, I'm telling you this is easy to do. No need to change kernel,
>even, just needs recent -mm.

This is good.

>
>								Pavel
>--
>Thanks, Sharp!

Who the heck is Sharp, and why do you always thank him?


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: CE Linux Forum PM Requierments WiKi is available for review and comment.

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Hi!

> >4. device power management seems to be missing. What is "OS
> >throttling"?
> >
> 
> I'll add some stuff on device power management.  
> 
> OS throttling is the pacing of work the OS is allowed to do to maintain
> some power or thermal budget constraints.

Hmm, okay, yes, that would be useful for machines that can't do
throttling in hardware.

> >7.1 if your hardware can damage itself or hurt user *FIX YOUR
> >HARDWARE*! Will you argue that overcharging li-ion to explosion is also
> ok?
> 
> Having your hardware catch on fire or exploding is not ok.  I'll
> re-write this a bit to avoid the inference of buggy hardware.   The
> point is that software support is needed to do a good job for some of
> these applications.
> 
> However; Having the OS help avoid deep discharging your cell phone or
> I-Pod battery because of some bug would not be unreasonable.

Do li-ion batteries really care about deep discharging in
cellphone/ipod applications? I thought single-li-ion solutions don't
mind being deeply discharged.

(In fact, that's what I'm now doing with li-ion in sharp sl-5500 --
collie; I'm running without any powermanagement, so it dies when
battery can no longer support CPU. I guess that's counts as deep discharge.)

> Neither is having OS support running on hardware that is built without
> active cooling that avoids the HW doing an emergency power off and
> loosing the users data.

NMI watchdog / SMM comes to mind. But SMM is unlikely to be option on
Arm machines.

> >--
> >Thanks, Sharp!
> 
> Who the heck is Sharp, and why do you always thank him?

That's a signature... Sharp is Japaneese firm, maybe you've heard
about them :-). Send me handheld computer, and that line becomes
"Thanks, Intel" ;-).
							Pavel
-- 
Picture of sleeping (Linux) penguin wanted...

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: CE Linux Forum PM Requierments WiKi is available for review and comment.

[Gross, Mark]

[-- Attachment #1: Type: text/plain, Size: 3207 bytes --]



>-----Original Message-----
>From: Pavel Machek [mailto:pavel@suse.cz]
>Sent: Tuesday, March 21, 2006 12:36 PM
>To: Gross, Mark
>Cc: linux-pm@osdl.org; mli_tech@groups.osdl.org; celinux-
>dev@tree.celinuxforum.org; PMWG@LIST.CELINUXFORUM.ORG
>Subject: Re: [linux-pm] CE Linux Forum PM Requierments WiKi is
available
>for review and comment.
>
>Hi!
>
>> >4. device power management seems to be missing. What is "OS
>> >throttling"?
>> >
>>
>> I'll add some stuff on device power management.
>>
>> OS throttling is the pacing of work the OS is allowed to do to
maintain
>> some power or thermal budget constraints.
>
>Hmm, okay, yes, that would be useful for machines that can't do
>throttling in hardware.

Even platforms that can throttle in hardware, it could make sense for to
throttle the OS.  

I think a person may want to throttle what work a laptop is doing as a
function of being tethered or remaining battery life.  If all you want
to do is finish those last few edits to a file before your battery cuts
you off for the rest of a long flight, you will be very willing to shut
down most (all?) processing that's not related to what you are editing.
Cron jobs, automatic spell checking, sound subsystems, screen savers,
pretty much anything not related to your editing will pull down your
battery.  Most of these can be shut down from user mode, some things may
be easier to implement robustly with some kernel support.  

One idea is to extend the SCHED_BATCH idea to know about power state to
avoid running some things when un-tethered or under low battery
conditions.

>
>> >7.1 if your hardware can damage itself or hurt user *FIX YOUR
>> >HARDWARE*! Will you argue that overcharging li-ion to explosion is
also
>> ok?
>>
>> Having your hardware catch on fire or exploding is not ok.  I'll
>> re-write this a bit to avoid the inference of buggy hardware.   The
>> point is that software support is needed to do a good job for some of
>> these applications.
>>
>> However; Having the OS help avoid deep discharging your cell phone or
>> I-Pod battery because of some bug would not be unreasonable.
>
>Do li-ion batteries really care about deep discharging in
>cellphone/ipod applications? I thought single-li-ion solutions don't
>mind being deeply discharged.
>

Your correct, see halfway down
http://www.buchmann.ca/article23-page1.asp

>(In fact, that's what I'm now doing with li-ion in sharp sl-5500 --
>collie; I'm running without any powermanagement, so it dies when
>battery can no longer support CPU. I guess that's counts as deep
>discharge.)
>
>> Neither is having OS support running on hardware that is built
without
>> active cooling that avoids the HW doing an emergency power off and
>> loosing the users data.
>
>NMI watchdog / SMM comes to mind. But SMM is unlikely to be option on
>Arm machines.
>

Yup.  That's one of the troubles with ACPI on CE platforms.

>> >--
>> >Thanks, Sharp!
>>
>> Who the heck is Sharp, and why do you always thank him?
>
>That's a signature... Sharp is Japaneese firm, maybe you've heard
>about them :-). Send me handheld computer, and that line becomes
>"Thanks, Intel" ;-).

Oh! Ok, that makes sense.  BTW careful what you wish for....

--mgross


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: CE Linux Forum PM Requierments WiKi is available for review and comment.

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

Hi!

> >Hmm, okay, yes, that would be useful for machines that can't do
> >throttling in hardware.
> 
> Even platforms that can throttle in hardware, it could make sense for to
> throttle the OS.  

Well, certainly. If you want to throttle to 1% and hardware can only
throttle to 30%, you need to do it in software.

> I think a person may want to throttle what work a laptop is doing as a
> function of being tethered or remaining battery life.  If all you want
> to do is finish those last few edits to a file before your battery cuts
> you off for the rest of a long flight, you will be very willing to shut
> down most (all?) processing that's not related to what you are editing.
> Cron jobs, automatic spell checking, sound subsystems, screen savers,
> pretty much anything not related to your editing will pull down your
> battery.  Most of these can be shut down from user mode, some things may
> be easier to implement robustly with some kernel support.  

That will be userland parts, I'd say.

> One idea is to extend the SCHED_BATCH idea to know about power state to
> avoid running some things when un-tethered or under low battery
> conditions.

Idle thread with realtime priority could do parts of what you want.

> >> >Thanks, Sharp!
> >>
> >> Who the heck is Sharp, and why do you always thank him?
> >
> >That's a signature... Sharp is Japaneese firm, maybe you've heard
> >about them :-). Send me handheld computer, and that line becomes
> >"Thanks, Intel" ;-).
> 
> Oh! Ok, that makes sense.  BTW careful what you wish for....

Well, I currently have collie (sharp sl-5500) for hacking, and spitz
(c-3000) for normal use. I would not mind hacking on something not as
obsolete.
								Pavel
-- 
Picture of sleeping (Linux) penguin wanted...

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]