Messages in this thread | | | Date | Thu, 26 Dec 2013 21:21:42 -0500 | From | Tejun Heo <> | Subject | Re: No freezing of kernel threads (was: Re: [GIT PULL] libata fixes for v3.13-rc5) |
| |
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
| |