[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1510311157420.9118-100000@netrider.rowland.org>
Date: Sat, 31 Oct 2015 12:01:36 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
cc: Jiri Kosina <jikos@...nel.org>, Pavel Machek <pavel@....cz>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
Christoph Hellwig <hch@....de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>, Tejun Heo <tj@...nel.org>,
<linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
<linux-pm@...r.kernel.org>
Subject: Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread
freezer
On Sat, 31 Oct 2015, Rafael J. Wysocki wrote:
> Runtime PM uses a freezable workqueue, allocated in pm_start_workqueue().
>
> That's because we don't want async runtime PM to happen during system
> suspend/resume and for good reasons, so if you want to remove the freezing
> mechanism, you need to stop that workqueue at the beginning of dpm_prepare
> and start it again at the end of dpm_complete().
The same sort of thing is true for the USB hub driver's workqueue.
Since it registers new devices (as a result of hotplugs), it must stop
running at the beginning of the dpm_prepare stage. Of course, that's
also a workqueue and not a kthread.
Alan Stern
--
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