[RFD] Freezing of kernel threads

[Rafael J. Wysocki]

Hi,

Having considered the issue of freezing (or not freezing) kernel threads for a
longer while I tend to agree with Linus that we shouldn't be freezing as many
kernel threads as we currently freeze, but there's one thing that he doesn't
seem to take into account.  Namely, there may be some kernel threads that
actually *want* (or need) to be frozen. :-)

For the suspend they may be kernel threads that otherwise would need some
special synchronization with some device drivers' .suspend() and .resume()
callbacks or fs-related kernel threads.  For the CPU hotplug they might be
kernel threads that otherwise would interfere with the removal or addition of
CPUs.  Still, in each case there seems to be a limited group of kernel threads
that may want to be frozen and the remaining kernel threads that shouldn't be
involved in any freezer-related actions at all.  However, we currently require
all kernel threads to take part in the freezing mechanism, which doesn't seem to
be correct.

It seems to me that, instead of asking *all* kernel threads to either set
PF_NOFREEZE or call try_to_freeze() in a suitable place, we should introduce
some mechanism allowing the kernel threads that *want* to freeze to register
with the freezer.  For example, we can use a per-task flag, say PF_FREEZABLE,
to indicate that given task is a kernel thread which wants (or needs) to be
frozen (for simplicity, I'll call it a 'freezable thread' from now on).
Alternatively, we can use a list of freezable kernel threads.  Regardless of
what actual mechanism is used, the freezer will only set TIF_FREEZE for
freezable kernel threads and these threads will be expected to call
try_to_freeze().  The remaining kernel threads (I'll call them 'normal') won't
need to do anything.

If this approach is used, the entire freezing-related complexity will only
affect the freezable kernel threads.  Moreover, it seems that we can precisely
define and document the rules to be followed by the freezable kernel threads
(for example, IMO it's reasonable to require a freezable kernel thread to
unregister from the freezer before it stops etc.) while the normal kernel
threads can be left in peace.

It also seems that we can transition from the current apporach to the one
outlined above in a quite straightforward way.  Namely, for this purpose we
need to identify the kernel threads that should be freezable, make them use the
new interface, and remove PF_NOFREEZE and try_to_freeze() from the remaining
kernel threads.  Later, if testing shows that we've overlooked some kernel
threads which need to be made freezable, we'll be able to add the "ability to
freeze" to these threads quite easily.

Of course, that would also require us to rewrite the freezer itself quite a
bit, but IMO it's worthy of doing.

Thoughts?

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/