On Thu, May 27, 2010 at 06:56:20PM +0200, Tejun Heo wrote: > Hello, > > On 05/27/2010 06:39 PM, Michael S. Tsirkin wrote: > >> Unless you're gonna convert every driver to use this > >> special kind of workqueue (and what happens when multiple tasks from > >> different cgroups share the driver?), > > > > We'll then create a workqueue per task. Each workqueue will have the > > right cgroup. But we are not trying to selve the problem for > > every driver. > > Ah... I see. You're gonna use multiple workqueues. Once concern that > I have is that this is abuse of workqueue interface to certain level > and depends on the implementation detail of workqueue rather than its > intended usage model. Well, this is why I proposed adding a new API for creating workqueue within workqueue.c, rather than exposing the task and attaching it to cgroups in our driver: so that workqueue maintainers can fix the implementation if it ever changes. And after all, it's an internal API, we can always change it later if we need. > stop_machine() was a similar case and in the > end it was better served by a different mechanism built on kthread > directly (cpu_stop). Wouldn't it be cleaner to use kthread directly > for your case too? You're basically trying to use workqueue as a > frontend to kthread, so... > > Thanks. Well, yes but we are using APIs like flush_work etc. These are very handy. It seems much easier than rolling our own queue on top of kthread. Makes sense? > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
