Hello, Oleg. On Sun, Sep 04, 2011 at 08:46:26PM +0200, Oleg Nesterov wrote: > > @@ -72,10 +72,6 @@ bool __refrigerator(bool check_kthr_stop) > > schedule(); > > } > > > > - spin_lock_irq(¤t->sighand->siglock); > > - recalc_sigpending(); /* We sent fake signal, clean it up */ > > - spin_unlock_irq(¤t->sighand->siglock); > > - > > Why? This recalc_sigpending() makes sense imho. Otherwise the user-space > tasks (almost) always return with TIF_SIGPENDING. May be we can do this > under "if (PF_KTRHREAD)". PF_KTHREAD no longer gets TIF_SIGPENDING set, so... > For example. Suppose the user-space task does wait_event_freezable()... > > Hmm. OTOH, wait_event_freezable() looks wrong anyway... So probably > this doesn't matter. ptrace_stop/get_signal_to_deliver doesn't need > this, probably we do not care about the other callers. Can you elaborate on it being wrong? Do you mean the possibility of leaking spurious TIF_SIGPENDING? > It seems, a lot of get_signal_to_deliver() calles also call > try_to_freeze() for no reason. Yeap, it doesn't really matter. In most cases userland tasks would get parked in the signal delivery path anyway and if a task is deep in the kernel, it should and usually does hit syscall restart path. Except for few special cases (maybe some of unfailable NFS calls), there'userland tasks shouldn't take try_to_freeze() path outside of signal delivery / job control path. Also, in general, I don't think it's a good idea to add non-trivial optimization like above to code path which is as cold as it gets without any backing data. The PM freezer used to busy loop until all tasks enter refrigerator. Nobody cares whether some tasks enter signal delivery path one more time. > So, yes, I am starting to think this change is fine too ;) Yeay. :) Thanks. -- tejun _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
