[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AC4E1D7.2070807@kernel.org>
Date: Fri, 02 Oct 2009 02:07:35 +0900
From: Tejun Heo <tj@...nel.org>
To: David Howells <dhowells@...hat.com>
CC: jeff@...zik.org, mingo@...e.hu, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, jens.axboe@...cle.com,
rusty@...tcorp.com.au, cl@...ux-foundation.org,
arjan@...ux.intel.com
Subject: Re: [PATCH 06/19] acpi: use queue_work_on() instead of binding workqueue
worker to cpu0
David Howells wrote:
> Tejun Heo <tj@...nel.org> wrote:
>
>> - kacpid_wq = create_singlethread_workqueue("kacpid");
>> - bind_workqueue(kacpid_wq);
>> - kacpi_notify_wq = create_singlethread_workqueue("kacpi_notify");
>> - bind_workqueue(kacpi_notify_wq);
>> - kacpi_hotplug_wq = create_singlethread_workqueue("kacpi_hotplug");
>> - bind_workqueue(kacpi_hotplug_wq);
>> + kacpid_wq = create_workqueue("kacpid");
>> + kacpi_notify_wq = create_workqueue("kacpi_notify");
>> + kacpi_hotplug_wq = create_workqueue("kacpi_hotplug");
>
> Doesn't that then create one worker thread per CPU and then eschew all but
> those attached to CPU 0? Sounds excessive, but presumably you deal with that
> in later patches.
Yeah, I'm just trying to strip down odd usages to ease conversion to
new mechanism, so between this patch and the actual new workqueue
implementation there will be whole lot of unused kthreads. After the
new workqueue, they automatically disappear. Also, the above can be
cleaned up such that only one of the workqueues remains afterwards.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists