On Tue, 1 Nov 2011 14:57:10 -0700 Tejun Heo <tj@xxxxxxxxxx> wrote: > Hey, Oleg. > > On Tue, Nov 01, 2011 at 08:46:01PM +0100, Oleg Nesterov wrote: > > On 11/01, Oleg Nesterov wrote: > > > > > > Or we can add TASK_FREEZABLE (like TASK_WAKEKILL), iirc we already > > > discussed this some time ago. And probably it makes sense to add the > > > generic wait_event_state(). > > > > Forgot to mention. I think that before anything else we need > > signal_wake_up_state(). For example, note that none of the callers > > of signal_wake_up(resume => true) in ptrace code wants to wake up > > the killable task. > > Yeah, agreed for both wait_event_state() and signal_wake_up_state(). > For now, let's go with the count/dont_count. Can you please write up > a patch for that? Jeff, does this seem okay to you? > Let me make sure I understand since I don't have a great grasp of the freezer internals... This will set the PF_FREEZER_SKIP flag on the task, which prevents try_to_freeze_tasks from incrementing the "todo" var for this process and should let the suspend proceed. So this really makes try_to_freeze_tasks set PF_FREEZING on the task, but not get upset that it doesn't actually call try_to_freeze(). Is that sufficient for a process that's just sleeping here? If so, guess I'll need to respin the NFS/RPC patches for this to do something similar around the sleeps there since they don't use wait_event_*. > For TASK_FREEZABLE, I'm not entirely sure. Combined with > wait_event_state(), it can definitely reduce the number of different > variants of wait_event_*(). Let's see. > wait_event_state() sounds like a wonderful idea regardless of what we do here. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
