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...
