Re: [RFD] Freezing of kernel threads

[Pavel Machek]

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.

Well.. It is actually a feature.

These days, you have to either add PF_NOFREEZE explicitly (which
hopefully means you know what you are doing) or add try_to_freeze() at
specific place.

If you fail to do that, we'll see freezer failure, quickly, and catch
the simple bug.

I'm afraid that if we default to "do not freeze by default", someone
will just port zfs, will know nothing about suspend, and his 
"write management info somewhere periodically" thread will corrupt
people's disks.

OTOH... perhaps suspend/resume is common enough operation that people
_know_ they need to stop their writing? ...no, I do not think we are
there yet.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/