From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932431Ab0E0Q5t (ORCPT ); Thu, 27 May 2010 12:57:49 -0400 Received: from hera.kernel.org ([140.211.167.34]:35418 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757964Ab0E0Q5r (ORCPT ); Thu, 27 May 2010 12:57:47 -0400 Message-ID: <4BFEA434.6080405@kernel.org> Date: Thu, 27 May 2010 18:56:20 +0200 From: Tejun Heo User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Michael S. Tsirkin" CC: Oleg Nesterov , Sridhar Samudrala , netdev , lkml , "kvm@vger.kernel.org" , Andrew Morton , Dmitri Vorobiev , Jiri Kosina , Thomas Gleixner , Ingo Molnar , Andi Kleen Subject: Re: [PATCH 2/3] workqueue: Add an API to create a singlethread workqueue attached to the current task's cgroup References: <1274227491.2370.110.camel@w-sridhar.beaverton.ibm.com> <20100527091426.GA6308@redhat.com> <20100527124448.GA4241@redhat.com> <20100527131254.GB7974@redhat.com> <4BFE9ABA.6030907@kernel.org> <20100527163954.GA21710@redhat.com> In-Reply-To: <20100527163954.GA21710@redhat.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (hera.kernel.org [127.0.0.1]); Thu, 27 May 2010 16:56:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. -- tejun