Hello, Neil. On Tue, Jul 15, 2014 at 06:13:17PM +1000, NeilBrown wrote: > Could do that (or per-client) but it doesn't really buy us anything does it? It does buy some. 1. The kworker threads are more likely to be cache-hot than explicit kthreads. 2. Workqueue is a lot eaiser to get right in terms of synchronization and freezing. 3. Workqueue mandates well-defined boundaries between separate execution instances which often makes it a lot easier to implement and update kernel-wide features such as like freezer and runtime kernel patching. > The state manager assumes it is single threads, so it would need to be > a single-threaded workqueue with always at least one thread running. > That is much the same as a kthread. > > And then there is that fact that the current code explicitly enabled SIGKILL > and maybe that is important. If SIGKILL handling is mandatory (really?), kthread_worker can be used for #2 and #3. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
