[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110825155957.GJ2803@mtj.dyndns.org>
Date: Thu, 25 Aug 2011 17:59:57 +0200
From: Tejun Heo <tj@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: rjw@...k.pl, menage@...gle.com, linux-kernel@...r.kernel.org,
arnd@...db.de
Subject: Re: [PATCH 06/16] freezer: make exiting tasks properly unfreezable
Hello, Oleg.
On Wed, Aug 24, 2011 at 04:14:31PM +0200, Oleg Nesterov wrote:
> > Hmmm... can it cause disk IOs after that point? I skimmed through and
> > couldn't spot one
>
> I am not sure. But, say, exit_files(). We can't know what f_op->flush()
> f_op->release() can do in general. Even without i/o the exiting task can
> do a lot of different things.
Yeah, what 'freeze' should do is a bit vague on the edges, I think.
The freezer can't really halt the whole system operation including
IOs. Tasks aren't the only source which can kick those off. There
are other asynchronous sources, timers, IRQs and bottom halves. For
actual disk IOs to at least SCSI/IDE devices, freezing isn't even
necessary. Queue processing is suspended via device suspend
mechanism. There were several drivers which didn't have proper device
suspend mechanism implemented (maybe we should implement generic queue
quiescing in block layer) but I don't know whether they are still like
that.
Anyways, freezing has never been a full solution to quiescing the
system prior to entering hibernation. It does make sense for userland
processes but depending on it for quiescing kernel activities
including IO can't be reliable. It should really be achieved by
device suspend (and maybe some midlayer suspending too) and I think
we're already pretty close to that. Rafael, can you please enlighten
us on the subject?
Another freezer user is the cgroup, for this, allowing killing to
finish is quite useful as it can be used for runaway cgroup control.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists