Hello, On 07/24/2010 09:14 PM, Michael S. Tsirkin wrote: >> I've created kthread_worker in wq#for-next tree and already converted >> ivtv to use it. Once this lands in mainline, I think converting vhost >> to use it would be better choice. kthread worker code uses basically >> the same logic used in the vhost_workqueue code but is better >> organized and documented. So, I think it would be better to stick >> with the original implementation, as otherwise we're likely to just >> decrease test coverage without much gain. >> >> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439 > > Sure, if we keep using workqueue. But I'd like to investigate this > direction a bit more because there's discussion to switching from kthread to > regular threads altogether. Hmmm? It doesn't have much to do with workqueue. kthread_worker is a simple wrapper around kthread. It now assumes kthread but changing it to be useable with any thread shouldn't be too hard. Wouldn't that be better? >> I don't think doing this before executing the function is correct, > > Well, before I execute the function work is NULL, so this is skipped. > Correct? > >> so >> you'll have to release the lock, execute the function, regrab the lock >> and then do the flush processing. >> >> Thanks. > > It's done in the loop, so I thought we can reuse the locking > done for the sake of processing the next work item. > Makes sense? Yeap, right. I think it would make much more sense to use common code when it becomes available but if you think the posted change is necessary till then, please feel free to go ahead. Thanks. -- 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
