[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C2A220B.8080006@linux.intel.com>
Date: Tue, 29 Jun 2010 09:40:43 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Tejun Heo <tj@...nel.org>
CC: Frederic Weisbecker <fweisbec@...il.com>,
torvalds@...ux-foundation.org, mingo@...e.hu,
linux-kernel@...r.kernel.org, jeff@...zik.org,
akpm@...ux-foundation.org, rusty@...tcorp.com.au,
cl@...ux-foundation.org, dhowells@...hat.com, oleg@...hat.com,
axboe@...nel.dk, dwalker@...eaurora.org, stefanr@...6.in-berlin.de,
florian@...kler.org, andi@...stfloor.org, mst@...hat.com,
randy.dunlap@...cle.com, Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 34/35] async: use workqueue for worker pool
On 6/29/2010 8:55 AM, Tejun Heo wrote:
> Hello,
>
> On 06/29/2010 05:52 PM, Frederic Weisbecker wrote:
>
>>>> If there is a question of slow ports to probe, then cmwq wouldn't seem the
>>>> right thing here, as it only forks when we go to sleep.
>>>>
>>> I lost you here. If something during boot has to burn cpu cycles
>>> (which it shouldn't, really), it has to burn cpu cycles and having
>>> multiple concurent threads won't help anything.
>>>
>> It would on SMP.
>>
> Oh, I see. Parallel cpu hogs. We don't have such users for async and
> I think using padata would be the right solution for those situations.
>
uh? clearly the assumption is that if I have a 16 CPU machine, and 12
items of work get scheduled,
that we get all 12 running in parallel. All the smarts of cmwq surely
only kick in once you've reached the
"one work item per cpu" threshold ???
--
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