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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
