Rafael J. Wysocki writes:
> They are mostly related to kernel threads, that we've already agreed no to
> freeze (except for the ones that want that, but they will be responsible for
> getting everything right). The initial patches for that are in -mm and more
> will come.
Serious question: which kernel threads would actually want to be
Threads that do no I/O at all don't care about suspend/resume and
don't need to be frozen in any case. Threads that issue I/O requests
in order to service incoming I/O requests can't be frozen because of
the possibility of deadlock. Which leaves threads that do I/O just
for the fun of it. :)
What am I missing?
> > Also, no-one has yet answered my fundamental objection to the freezer,
> > which is that the very kernel threads we would want to freeze are
> > often the same ones that we must not freeze, namely the threads that
> > issue I/O requests in order to satisfy incoming I/O requests.
> See above. We're moving away from freezing kernel threads.
I believe the distinction between threads and user processes is a
false one, because user processes can now do things that were formerly
only doable by kernel threads.
> > If there was an automatic way to construct the graph of dependencies
> > (including data flows) between tasks, and derive an ordering for
> > freezing that guarantees that all I/Os will get completed without
> > deadlocks, then I could accept the freezer. But we don't have
> > anything like that.
> No we don't.
> Still, my position is this:
> 1) The freezer (in the modified form, with the freezing of kernel threads
> limited to the ones that want to be frozen) is needed for hibernation.
> 2) The freezer is generally not needed for suspend, _but_ there are drivers
> in the tree that rely on it being used. Thus, at some point in time we can
Do you know which drivers they are? I'm happy to help hack things
> remove the freezer from the suspend code path, _but_ no sooner than we are
> sure that the majority of drivers is prepared for that.
> 3) In the meantime, if there are freezer-related problems, they should be
> fixed rather than used as arguments for immediate removal of it, because of 2).
I don't know how you can make the freezer completely deadlock-free
while still providing the guarantee that some drivers currently need,
without constructing the dependency graph I mentioned.
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]
[Video 4 Linux]
[Linux for the blind]