Messages in this thread |  | | Date | Wed, 31 Jan 2007 21:46:16 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture |
| |
On Thu, Feb 01, 2007 at 01:42:42PM +1100, Nigel Cunningham wrote: > Hi Paul. > > On Wed, 2007-01-31 at 18:31 -0800, Paul E. McKenney wrote: > > Good to hear from you, Nigel! > > Thanks :) > > > Should indeed be OK to freeze during suspend/hibernate. Will my > > schedule_timeout_interruptible() be sufficient to allow the freeze > > to happen, or do I need to add an explicit try_to_freeze()? > > You need a try_to_freeze() - the process has to enter the refrigerator() > function to be counted as frozen.
Even though it explicitly sleeps each time through the loop? Hmmm...
> > Ah, and I probably need to use the same trick that mtd_blktrans_thread() > > does to avoid having all my sleeps killed of by an errant signal: > > > > spin_lock_irq(¤t->sighand->siglock); > > sigfillset(¤t->blocked); > > recalc_sigpending(); > > spin_unlock_irq(¤t->sighand->siglock); > > > > Or is such paranoia unnecessary? > > Yeah. try_to_freeze() is a function now, so you can do something if > (try_to_freeze()) goto sleep_again if you so desire.
If try_to_freeze() succeeds, do I need to clean up signal state? It didn't look like it to me, but thought I should ask the expert!
My guess is that I can simply do:
try_to_freeze(); schedule_timeout_interruptible(HZ);
The schedule_timeout_interruptible() might return early, but if I don't care about getting a shorter than expected sleep, I am OK, right? Besides, one would have to get a couple of very closely spaced freeze_processes() calls for this to happen. ;-)
Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |