In many ways, "at all".
I _do_ realize the IO request queue issues, and that we cannot actually do
s2ram with some devices in the middle of a DMA. So we want to be able to
avoid *that*, there's no question about that. And I suspect that stopping
user threads and then waiting for a sync is practically one of the easier
ways to do so.
So in practice, the "at all" may become a "why freeze kernel threads?" and
freezing user threads I don't find really objectionable.
But as Paul pointed out, Linux on the old powerpc Mac hardware was
actually rather famous for having working (and reliable) suspend long
before it worked even remotely reliably on PC's. And they didn't do even
that.
(They didn't have ACPI, and they had a much more limited set of devices,
but the whole process freezer is really about neither of those issues. The
wild and wacky PC hardware has its problems, but that's _one_ thing we
can't blame PC hardware for ;)
Yes.
Did you actually _do_ the "grep" (with the fixed argument)?
I had two totally independent points. #1 was that you yourself have been
fixing bugs in this area. #2 was the result of that grep. It's absolutely
_empty_ except for the define to add that interface.
NOBODY USES IT!
Now, grep for the same interface that creates _non_freezeable workqueues.
Put another way:
[torvalds@woody linux]$ git grep create_workqueue | wc -l
35
[torvalds@woody linux]$ git grep create_freezeable_workqueue | wc -l
1
and that _one_ hit you get for the "freezeable" case is not actually a
user, it's the definition!
Ie my point is, nobody wants freezeable kernel threads. Absolutely nobody.
Yet we have all this support for freezing them (or rather, we freeze them
by default, and then we have all this support for _not_ doing that wrong
default thing!)
So yes, I think it would be interesting to just stop freezing kernel
threads. Totally.
Linus
-
