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
WARNING: multiple messages have this Message-ID (diff)
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: 16+ 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 15:24 ` Alan Stern
2013-02-20 20:28 ` Eric W. Biederman
2013-02-20 20:28 ` Eric W. Biederman
2013-02-20 20:48 ` Alan Stern
2013-02-20 20:48 ` Alan Stern
2013-02-20 21:36 ` Eric W. Biederman [this message]
2013-02-20 21:36 ` Eric W. Biederman
2013-02-20 21:58 ` Alan Stern
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.