public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
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

  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