Messages in this thread | | | Date | Mon, 16 Dec 2013 11:05:42 -0500 | From | Tejun Heo <> | Subject | Re: [PATCH] libata, freezer: avoid block device removal while system is frozen |
| |
Hello, Ming.
On Mon, Dec 16, 2013 at 09:24:40PM +0800, Ming Lei wrote: > You mean there are still some write I/O scheduled after processes are > frozen? by unfreezable kernel threads?
By unfreezable kernel threads, timer, bh, freezable kernel threads, whatever really. Please note that freezer doesn't enforce any order in how the target tasks are frozen. There's no mechanism to guarantee that flusher is frozen after all other freezable tasks are frozen. There isn't even a meachnism which guarantees flusher flushes all its queues before getting frozen. There's no interlocking whatsoever. The only thing which happens is that we flush all filesystems before freezing the kernel threads, so the queues are *likely* to be empty.
I think trying to control all IO sources using the freezer is a fundamentally flawed idea. There are N sources which are difficult to track down reliably while there is *single* queue all those have to go through, which needs to be quiesced anyway. The only thing which makes sense is controlling the queue.
Maybe it really is necessary for hibernation. If so, let's please make it something tailored for that purpose - quiesce only the ones which are actually relevant and in the places where it's necessary. Not this "we stopped most of the system, whatever that means, and it feels good" thing which doesn't really solve anything while introducing this fuzzy wishful idea of mostly stopped system and giant lock semantics all over the place.
Thanks.
-- tejun
| |