On Mon, 31 May 2010 09:03:29 +1000 Neil Brown <neilb@xxxxxxx> wrote: > > Well, please have a look at the Alan Stern's proposal here: > > http://lkml.org/lkml/2010/5/29/77 > > > > Thanks for the reference. > Some of the details are different, but the idea seems almost exactly the same > as mine. > The apparent dependence on signals makes me feel a little uncomfortable > (interfaces that depend on using signals seem to be easy to use wrongly), but > I don't think that is a serious flaw. > > Maybe the biggest difference is philosophical. Alan's proposal appears to be > adding a new feature. Mine presents as trying to fix an existing feature so > that it can be used reliably. > It is easier to argue against a feature than against a bug-fix (??). Addendum... The use of signals by Alan here got me thinking.. and combining it which what Alan Cox and Thomas Gleixner (and others?) have been saying about detecting idleness led me down an interesting path that I thought I would share. An absolutely minimal change to allow a user-space initiated auto-suspend to be race-free would be achieved by placing an interruptible wait between pm_notifier_call_chain(PM_SUSPEND_PREPARE); and suspend_freeze_processes(); which waits for all kernel threads to have passed through an 'idle' state. Then any wake event that happened after the PM_SUSPEND_PREPARE would presumably either abort the suspend later, or would cause an immediate wake-up. Any event that happened before the PM_SUSPEND_PREPARE would have been fully processed by any kernel thread and so would be queued for user-space (or have been discarded). If we then require any process that handles wakeup events to use the equivalent of fcntl(F_SETOWN) to direct a SIGIO (or other signal) at the process which requests the suspend, then wakeup events won't be lost. They will either send a signal to the suspend-daemon in time to abort the suspend, or will be late enough to either abort the suspend in-kernel, or trigger an immediate wakeup. Yes: this would require quite a large change of the android code, and the F_SETOWN usage is fairly ugly, but balanced against it actually working and it being minimal, that might be OK. The hardest part would be waiting for all kernel-threads to pass through idle (or all threads to pass through idle or user-space). We'd need help to make that work, but at least it would be a fairly localised change. Maybe it is something to keep in mind when other possibilities have proven intractable. NeilBrown _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
