On Thu, 16 Feb 2012, Tejun Heo wrote: > Hello, (cc'ing Rafael and Jens) > > On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote: > > My question to all of you: Should system_nrt_wq be made freezable, or > > should I create a new workqueue that is both freezable and > > non-reentrant? And if I do, which of the usages above should be > > converted to the new workqueue? > > Let's make it explicit that the wq is freezable. I'm a bit > uncomfortable with the way it's headed. What we should be doing is > implementing plugging of request queue for all regular requests while > suspend is in progress and then annotate the ones which should go > through. We're trying to do it the other way around. Um. I don't think I can audit all the calls in the kernel that submit block requests and determine which ones need to be allowed while a system sleep is in progress. > Also, in general, I don't think using freezing widely for kernel > threads / wqs is a good idea. Plugging device access at subsystem > layer should cover most cases and we have notifiers to implement such > support and to handle special cases. There are even code paths which > try to determine whether system went through PM operation by looking > at whether %current went through the freezer. IMHO, we'll be better > off with removing freezer support for kthreads. :( Well, there are some dedicated threads that exist for no other purpose than to do I/O to devices and to handle hotplug/unplug events. I don't see any reason not allow such threads to be freezable. It's a quick, convenient method for getting them out of the way. More general-purpose threads, like the async_schedule reservoir and workqueue threads, are a different story. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
