[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Zygo Blaxell on 27 May 2010 15:40 On Thu, May 27, 2010 at 07:56:58PM +0100, Matthew Garrett wrote: > Even if it's using poll, it could block purely on the display if X turns > the screen off between poll() waking and the write being made. That's what fcntl(fd, F_SETFL, O_NONBLOCK) is for. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 27 May 2010 15:50 On Thu, 27 May 2010 20:29:26 +0100 Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote: > > > The scheduler can happily do this, the power management will also > > recognize STOPPED processes as no impediment to suspend. > > But wakeup events won't be delivered to STOPped processes, and there's Try the following cat <pipe kill -STOP catpid echo "wombats are cool" > pipe kill -CONT catpid it will echo "wombats are cool" The event was not lost. > also the race of an application being in the middle of handling a wakeup > event when you send it the signal. sigmask() -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 27 May 2010 16:00 On Thu, 27 May 2010 19:23:03 +0100 Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > Actually, the reverse - there's no terribly good way to make PCs work > > > with scheduler-based suspend, but there's no reason why they wouldn't > > > work with the current opportunistic suspend implementation. > > > > How does that solve the problems you mentioned above ? Wakeup > > guarantees, latencies ... > > Latency doesn't matter because we don't care when the next timer is due > to expire. In your specific current implementation. It matters a hell of a lot in most cases. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 27 May 2010 16:20 On Thu, May 27, 2010 at 08:53:33PM +0100, Alan Cox wrote: > On Thu, 27 May 2010 20:29:26 +0100 > Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > > But wakeup events won't be delivered to STOPped processes, and there's > > Try the following > > cat <pipe > kill -STOP catpid > > echo "wombats are cool" > pipe > kill -CONT catpid > > it will echo "wombats are cool" > > The event was not lost. Not lost, but not delivered. So you need your policy agent to send SIGCONT when you receive any wakeup event, which either means proxying all your network traffic through your policy agent or having some mechanism for alerting the policy agent whenever you leave the deep idle state. > > also the race of an application being in the middle of handling a wakeup > > event when you send it the signal. > > sigmask() Doesn't help - I may be hit by the signal between the poll() unblocking and me having the opportunity to call sigmask(). -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on 27 May 2010 16:30
On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > We were talking about PCs. Suspend-as-c-state is already implemented for > > > OMAP. > > > > Ah, now we talk about PCs. And all of a sudden the problem of the > > unability of determining wakeup sources is not longer relevant ? So > > how do you guarantee that we don't miss one if we cant figure out > > which ones are kept alive in S3 ? > > A wakeup event is defined as one that wakes the system - if a system > can't be woken by a specific event then it's impossible to lose it, > since it wasn't a wakeup event to begin with. So where is the problem ? > > > > So the only thing you are imposing to app writers is to use an > > > > interface which solves nothing and does not save you any power at > > > > all. > > > > > > It's already been demonstrated that the Android approach saves power. > > > > Demonstrated ? Care to explain me how it makes a difference: > > > > while (1) { > > block(); > > read(); > > process_event(); > > unblock(); > > ---> suspend > > <--- resume > > do_crap(); 1000000 cycles > > } > > > > vs. > > > > while (1) { > > read(); > > ---> suspend > > <--- resume > > process_event(); > > do_crap(); 1000000 cycles > > } > > > > You spend the damned 10000000 cycles in any case just at a different > > point in time. So if you are so convinced and have fully understood > > all the implications, please enlighten me why do_crap() costs less > > power with the blockers approach. > > Consider the case where the read() is non-blocking. Which I consider in the same range as the application which does: while (1); > > 1) The kernel blocker does not guarantee that the lousy app has > > processed the event. It just guarantees that the lousy app has > > emptied the input queue. So what's the point of the kernel blocker > > in that case ? > > Yes, I think you're right here. You need the userspace component as well > for this to work correctly. > > > 2) What's the difference on setting that app to QoS(NONE) and let the > > kernel happily ignore it. > > What sets that flag, and how does it interact with an application that > never makes a blocking system call? QoS(NONE) would be default policy for untrusted apps in the same way as you'd refuse the usage of supsend blockers for untrusted apps. while (1); is definitely not an application which should be granted trusted rights, right ? block_suspend(); while(1); is the same as: QoS(minimal latency); while(1); So if you really go to trust an "while (1);" application you better make sure that this app has the appropriate QoS(NONE) or QoS(10s) call in it before letting it lose. > > Come up with real explanations and numbers and not just the "it has > > been demonstrated" chant which is not holding water if you look at the > > above. > > The numbers were earlier in the thread. Numbers, yes. But I really give a sh*t about numbers w/o a detailed explanation of the scenario which created those numbers. And if the numbers boil down to: we handle the untrusted app which does "while (1);" then they are absolutely useless. > > The kernel history is full of examples where crappy solutions got > > rejected and kept out of the kernel for a long time even if there was > > a need for them in the application field and they got shipped in > > quantities with out of tree patches (NOHZ, high resolution timers, > > ...). At some point people stopped arguing for crappy solutions and > > sat down and got it right. The problem of power management and > > opportunistic suspend is not different in any way. > > Yes, and I'd agree with this if anyone seemed to have any idea how to do > it right. But despite all the heat and noise in this thread, all we've > got is an expression that it should be handled by the scheduler (a > viewpoint I agree with) without any explanation of how to switch > policies in such a way that applications idle without losing wakeup > events. Why in the world should they lose wakeup events ? If an app goes idle, it goes idle because it is waiting for an event. There is no other sane reason except for those apps which are untrusted and force idled. And for those you agreed already the suspend blockers don't solve anything as they are either not implemented or the app is not trusted to use them. So we are back to round one of the whole discussion: Is it worth to create an utter mess in the kernel just to handle a subset of crappy coded applications ? And the answer stays the same: No, not at all. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |