From: ebiederm@xmission.com (Eric W. Biederman)
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Li Fei <fei.li@intel.com>,
pavel@ucw.cz, rjw@sisk.pl, len.brown@intel.com, mingo@redhat.com,
peterz@infradead.org, akpm@linux-foundation.org,
viro@zeniv.linux.org.uk, gorcunov@openvz.org,
rientjes@google.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, chuansheng.liu@intel.com,
biao.wang@intel.com
Subject: Re: [PATCH] freezer: configure user space process frozen along with kernel threads
Date: Wed, 20 Feb 2013 13:36:19 -0800 [thread overview]
Message-ID: <87zjyyekh8.fsf@xmission.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1302201541000.1671-100000@iolanthe.rowland.org> (Alan Stern's message of "Wed, 20 Feb 2013 15:48:43 -0500 (EST)")
Alan Stern <stern@rowland.harvard.edu> writes:
> On Wed, 20 Feb 2013, Eric W. Biederman wrote:
>
>> >> Why can't the fuse filesystem freeze when there are requests pending?
>> >
>> > It _can_ freeze (that is, the fuse daemon can). The problem is that
>> > tasks _using_ the fuse filsystem can't if the daemon doesn't respond.
>>
>> Which is what I meant when I said that the fuse filesystem couldn't
>> freeze.
>
> Oh, okay. But it's no different from any other filesystem in that
> respect. Processes generally can't be frozen while they are waiting
> for filesystem I/O to complete. In many cases they can't receive
> signals either (they are in an uninterruptible wait state).
Ick. So the process freezer and all network filesystems has problems?
Especially nfs?
>> > These tasks are stuck in uninterruptible wait states deep in the
>> > filesystem layer, probably holding important locks. They can't be
>> > frozen until the outstanding requests complete.
>>
>> Why is it that processes that can be preempted can't be frozen?
>
> There's a big difference between preemption and freezing: Preemption
> is involuntary whereas freezing is voluntary. It's like the difference
> between preemptive and cooperative multitasking.
I hadn't realized freezing was voluntary. That certainly seems like a
pain.
> Processes can be frozen only by making explicit checks, and they
> mustn't be frozen while they are holding locks that would prevent other
> processes from reaching one of those checks.
>
>> At most I would suggest that processes be frozen in reverse priority
>> order. Which unless there is a priority inversion should solve this
>> problem without an additional proc file.
>
> Do fuse daemons (and the processes they rely upon) run with elevated
> priority?
I don't know if the daemons are of an elevated scheduling priority today
but if they aren't it is as easy to require an elevated scheduling
priority as it is to require a magic freezer priority. Furthermore if
they don't run at an elevated priority there is the possibility of
priority inversion.
With a little care you might even be able to drop the kernel thread
special case if you freeze processes by prirority.
Eric
next prev parent reply other threads:[~2013-02-20 21:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 2:15 [PATCH] freezer: configure user space process frozen along with kernel threads Li Fei
2013-02-20 9:05 ` Cyrill Gorcunov
2013-02-20 13:46 ` Li, Fei
2013-02-20 13:51 ` Eric W. Biederman
2013-02-20 15:24 ` Alan Stern
2013-02-20 20:28 ` Eric W. Biederman
2013-02-20 20:48 ` Alan Stern
2013-02-20 21:36 ` Eric W. Biederman [this message]
2013-02-20 21:58 ` Alan Stern
2013-02-20 22:49 ` Pavel Machek
2013-02-20 22:39 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zjyyekh8.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=biao.wang@intel.com \
--cc=chuansheng.liu@intel.com \
--cc=fei.li@intel.com \
--cc=gorcunov@openvz.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox