On Thu 2009-03-05 18:42:05, Uli Luckas wrote: > On Wednesday, 4. March 2009, Pavel Machek wrote: > > Hi! > > > > > > > here is network packets. You just don't want to open/close a fd for > > > > > every network packet that you process. Neither for serial data, > > > > > bluetooth packets, ... > > > > > > > > You mix userland and kernel users. > > > > > > No. I don't. > > > The idea of wake locks was to hand locks over from a driver's interrupt > > > all the way to userspace. > > > This is done in an interlocked way to ensure that the device does not > > > suspend from the time of interrupt until userspace has handled the event > > > that caused the interrupt (e.g. A modem sending "RING" on the serial > > > line). > > > Basically, in a timerless wake lock implementation userspace has to take > > > a wake lock every time select returns. > > > > Well... in case it is really performance critical, we may want new > > syscalls. > > > > Actually, given how deep change of semantics this is, new syscalls may > > be good idea. > > > > Or better yet eliminate polling from userspace apps and just avoid > > suspending whenever userspace is running (like sleepy patches do). > > Pavel > I don't know the details of sleepy linux so I'd appreciate if someone can > eluminate if the following scenarios could be handled efficiently with sleepy > linux: > 1) You wake up through RTC, read the battery, update the color of your > fancy 'battery good' LED and go back to sleep imediately. The real work > takes milliseconds. This should work. > 2) You send a request to the internet and go idle by selecting for an answer. > You probably don't want to go to sleep as you know, the answer will be > there shortly. Way to get this to work would be to keep the system woke up 300msec or so after each network packet -- assuming that if one came another is probably coming soon. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
