From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: No freezing of kernel threads (was: Re: [GIT PULL] libata fixes for v3.13-rc5) Date: Thu, 26 Dec 2013 21:21:42 -0500 Message-ID: <20131227022142.GD16483@htj.dyndns.org> References: <20131226190120.GC16483@htj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org To: Alan Stern Cc: "Rafael J. Wysocki" , Linus Torvalds , Kernel development list , linux-ide@vger.kernel.org, Linux-pm mailing list List-Id: linux-ide@vger.kernel.org Hello, On Thu, Dec 26, 2013 at 09:14:49PM -0500, Alan Stern wrote: > I can't disagree with this. But the design may well be perfectly > adequate for some use cases. Given a workqueue or kthread which should > not operate during system sleep, we have to: > > Tell the wq/thread to stop running because a sleep is about > to start, and > > Provide a function the wq/thread can call to put itself on > hold for the duration of the sleep. > > The freezer does both these things pretty efficiently. Problems may I don't even like the interface itself. It's too implicit and spread all over the place - we basically had to spread it all over the wait interfaces, and the implementation is far more involved than called for. I don't know how you're defining "efficiently" but that isn't a word I'd use to describe the freezer. > So you're suggesting changing the kthread to a workqueue thread, but > keeping the existing list of scheduled events instead of relying on the > workqueue's own queue of work items? What's the advantage? Making > such a change wouldn't simplify anything. Well, that'd be an easy first step which does away with the dedicated kthread, likely reduces cache footprint and allows use of wq synchronization / freezing constructs which are easier to deal with. More involved conversion would of course be doable but even simple conversion seems like a win. Thanks. -- tejun