On Saturday, 28 April 2007 03:12, Linus Torvalds wrote:
>
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> >
> > > It's doubly bad, because that idiocy has also infected s2ram. Again,
> > > another thing that really makes no sense at all - and we do it not just
> > > for snapshotting, but for s2ram too. Can you tell me *why*?
> >
> > Why we freeze tasks at all or why we freeze kernel threads?
>
> 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 ;)
We freeze user space processes for the reasons that you have quoted above.
Why we freeze kernel threads in there too is a good question, but not for me to
answer. I don't know. Pavel should know, I think.
> > > git grep create_freezeable_workthread
> >
> > s/workthread/workqueue/
>
> Yes.
>
> > > and ponder the end results of that grep. If you don't see something wrong,
> > > you're blind.
> >
> > This was a mistake, quite unrelated to the point you're making.
>
> 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!
The reason is pretty simple.
We wanted to drop that interface altogether, because it was broken (my fault),
but Oleg suggested that we keep it so that we could fix and use it in the
future (for purposes other than the hibernation, though).
> 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.
That's freezable workqueues only. :-)
> 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.
Okay, I'll do that.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
