[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070130102718.f03f37d8.akpm@osdl.org>
Date: Tue, 30 Jan 2007 10:27:18 -0800
From: Andrew Morton <akpm@...l.org>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: paulmck@...ux.vnet.ibm.com, Ingo Molnar <mingo@...e.hu>,
dipankar@...ibm.com, Gautham Shenoy <ego@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug
On Tue, 30 Jan 2007 17:44:47 +0100
"Rafael J. Wysocki" <rjw@...k.pl> wrote:
> > I need to look at all uses of PF_NOFREEZE -- as I understand the
> > code, processes marked PF_NOFREEZE will continue running, potentially
> > interfering with the hotplug operation. :-(
> >
> > I will pass my findings on to this list.
>
> Well, I did it some time ago, although not very thoroughly.
>
> AFAICS there are not so many, but one that stands out is the worker threads.
> We needed two of them to actually go to sleep, so now it's possible to create
> a "freezeable workqueue" the worker thread of which will not set PF_NOFREEZE,
> but currently this is only used by XFS.
Or we can create a variant of freeze_processes which ignores PF_NOFREEZE.
As I said eariler, we might need to change the freezer code for this
application. In fact we should do so: that sys_sync() call in there is
quite inappropriate, as is, I suppose, the two-pass freeze attempt. As are
the nice printks, come to that.
Pretty simple stuff though.
-
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