Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Arve Hjønnevåg on 3 Aug 2010 01:00 On Sun, Aug 1, 2010 at 6:10 PM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote: .... >> Another one: freezing whole cgroups..... we have that today. it >> actually works quite well.... of course the hard part is the decision >> what to put in which cgroup, and at what frequency and duration you let >> cgroups run. > > Indeed, the Android guys seemed to be quite excited by cgroup freezing > until they thought about the application-classification problem. > Seems like it should be easy for some types of applications, but I do > admit that apps can have non-trivial and non-obvious dependencies. > The dependencies is what made this solution uninteresting to us. For instance, we currently use cgroup scheduling to reduce the impact of some background tasks, but we occasionally saw a watchdog restart of the system process were critical services were waiting on a kernel mutex owned by a background task for more than 20 seconds. If we froze a cgroup instead, we would not hit this particular problem since tasks cannot be frozen while executing kernel code the same way they can be preempted, but nothing prevents a task from being frozen while holding a user-space resource. -- Arve Hj�nnev�g -- 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: david on 3 Aug 2010 01:10 On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: > 2010/8/2 <david(a)lang.hm>: >> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: >> >>> On Mon, Aug 2, 2010 at 5:08 PM, �<david(a)lang.hm> wrote: >>>> >>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote: >>>> >>>> >>>> you are close, but I think what I'm proposing is actually simpler >>>> (assuming >>>> that the scheduler can be configured to generate the appropriate stats) >>>> >>>> my thought was not to move applications between cgroups as they >>>> aquire/release the suspend-block lock, bur rather to say that any >>>> application that you would trust to get the suspend-block lock should be >>>> in >>>> cgroup A while all other applications are in cgroup B >>>> >>>> when you are deciding if the system shoudl go to sleep because it is >>>> idle, >>>> ignore the activity of all applications in cgroup B >>>> >>>> if cgroup A applications are busy, the system is not idle and should not >>>> suspend. >>>> >>> >>> Triggering suspend from idle has been suggested before. However, idle >>> is not a signal that it is safe to suspend since timers stop in >>> suspend (or the code could temporarily be waiting on a non-wakeup >>> interrupt). If you add suspend blockers or wakelocks to prevent >>> suspend while events you care about are pending, then it does not make >>> a lot of sense to prevent suspend just because the cpu is not idle. >> >> isn't this a matter of making the suspend decision look at what timers have >> been set to expire in the near future and/or tweaking how long the system >> needs to be idle before going to sleep? >> > > You are describing low power idle modes, not suspend. Most timers stop > in suspend, so a timer set 10 seconds from now when entering suspend > will go off 10 seconds after resume so it should have no impact on how > long you decide to stay in suspend. so what is the fundamental difference between deciding to go into low-power idle modes to wake up back up on a given point in the future and deciding that you are going to be idle for so long that you may as well suspend until there is user input? David Lang
From: Arve Hjønnevåg on 3 Aug 2010 01:10 2010/8/2 <david(a)lang.hm>: > On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: > >> On Mon, Aug 2, 2010 at 5:08 PM, �<david(a)lang.hm> wrote: >>> >>> On Mon, 2 Aug 2010, Paul E. McKenney wrote: >>> >>> >>> you are close, but I think what I'm proposing is actually simpler >>> (assuming >>> that the scheduler can be configured to generate the appropriate stats) >>> >>> my thought was not to move applications between cgroups as they >>> aquire/release the suspend-block lock, bur rather to say that any >>> application that you would trust to get the suspend-block lock should be >>> in >>> cgroup A while all other applications are in cgroup B >>> >>> when you are deciding if the system shoudl go to sleep because it is >>> idle, >>> ignore the activity of all applications in cgroup B >>> >>> if cgroup A applications are busy, the system is not idle and should not >>> suspend. >>> >> >> Triggering suspend from idle has been suggested before. However, idle >> is not a signal that it is safe to suspend since timers stop in >> suspend (or the code could temporarily be waiting on a non-wakeup >> interrupt). If you add suspend blockers or wakelocks to prevent >> suspend while events you care about are pending, then it does not make >> a lot of sense to prevent suspend just because the cpu is not idle. > > isn't this a matter of making the suspend decision look at what timers have > been set to expire in the near future and/or tweaking how long the system > needs to be idle before going to sleep? > You are describing low power idle modes, not suspend. Most timers stop in suspend, so a timer set 10 seconds from now when entering suspend will go off 10 seconds after resume so it should have no impact on how long you decide to stay in suspend. > to properly do a good job at suspending hyperagressivly you need to look at > when you need to wake back up (after all, if you are only going to sleep for > 1 second, it makes no sense to try and enter a sleep state that takes .5 > seconds to get into and .6 seconds to get out of, you need to pick a lighter > power saving mode) > > if you really want to have the application be able to say 'I am ready for > you to go to sleep NOW and I don't want any chance of waking back up until > the system is ready for me to do so' it may be possible to have a special > dev file that when a program attempts to read from it the program is > considered to have been idle forever (expiring any 'delay since last > activity' timers that are running for that process) and when the device > wakes back up (or after a little bit of time if the device decides not to go > back to sleep), allow the return from the blocking call to allow the app to > continue running. > > but I am not sure that something like that is needed. I think just checking > for timers that are due to expire 'soon' and tweaking how long the system > must be 'idle' before it decides to go to sleep should be good enough. > > David Lang > -- Arve Hj�nnev�g -- 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: Florian Mickler on 3 Aug 2010 07:30 On Mon, 2 Aug 2010 21:41:17 -0700 Paul Menage <menage(a)google.com> wrote: > On Mon, Aug 2, 2010 at 2:06 AM, <david(a)lang.hm> wrote: > > > > yes, it could mean a doubleing in the number of cgroups that you need on a > > system. and if there are other features like this you can end up in a > > geometric explosion in the number of cgroups. > > No, it would be additive - you can mount different subsystems on > separate hierarchies. So if you had X divisions for memory, Y > divisions for CPU and Z divisions for suspend-blocking (where Z=2, > probably?) you could mount three separate hierarchies and have X+Y+Z > complexity, not X*Y*Z. > > (Not that I have a strong opinion on whether cgroups is an appropriate > mechanism for solving this problem - just that the problem you forsee > shouldn't occur in practice). > > Paul Ah yes, mea culpa. I've got this wrong. Cheers, Flo -- 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: Florian Mickler on 3 Aug 2010 07:30
Hi! On Mon, 2 Aug 2010 21:38:12 -0700 Paul Menage <menage(a)google.com> wrote: > On Sun, Aug 1, 2010 at 11:53 PM, Florian Mickler <florian(a)mickler.org> wrote: > > > > Thinking about it.. I don't know much about cgroups, but I think a > > process can only be in one cgroup at a time. > > A thread can only be in one cgroup in each hierarchy at one time. You > can mount multiple cgroups hierarchies, with different resource > controllers on different hierarchies. > > > > > b) you can't use cgroup for other purposes anymore. I.e. if you want to > > have 2 groups that each only have half of the memory available, how > > would you then integrate the cgroup-ignore-for-idle-approach with this? > > You could mount the subsystem that provides the "ignore-for-idle" > support on one hierarchy, and partition the trusted/untrusted > processes that way, and the memory controller subsystem on a different > hierarchy, with whatever split you wanted for memory controls. > > Paul Thank you for the clarification. That renders my original objections more or less void. I've still got some doubts about the flexibility of this approach (think an open system with arbitrary software components). But with a userspace manager that sorts processes into the groups this may be a possible solution. But we should probably concentrate first on the requirements now. If we have a set of requirements everyone can agree too, we may be on our way to get a solution. Cheers, Flo -- 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/ |