Messages in this thread | | | Subject | Re: [RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture | From | Nigel Cunningham <> | Date | Fri, 02 Feb 2007 09:13:46 +1100 |
| |
Hi.
On Wed, 2007-01-31 at 21:46 -0800, Paul E. McKenney wrote: > 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...
Yes. Sleeping isn't enough - we have to be sure it won't wake up and perform work at inappropriate times (we don't know what process X might do if it did wake; the result could be an inconsistent image). It therefore needs to enter the refrigerator function so that the freezer code can ensure it remains inactive until the suspend-to-whatever cycle is complete.
> > > 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!
No, you don't need to. We have recalc_sigpending() in the refrigerator function.
> 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. ;-)
Yes, that looks good to me.
Regards,
Nigel
- 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/
| |