Re: [PATCH 4/7] sched: implement force_cpus_allowed()

[Tejun Heo <tj@kernel.org>]

Hello,

On 12/08/2009 09:10 PM, Peter Zijlstra wrote:
> Hotplug and deterministic are not to be used in the same sentence, its
> an utter slow path and I'd much rather have simple code than clever code
> there -- there's been way too many 'interesting' hotplug problems.

Slow and indeterminism comes in different magnitudes.

> If there is work being enqueued that takes more than a few seconds to
> complete then I'm thinking there's something seriously wrong and up to
> that point its perfectly fine to simply wait for it.
> 
> Furthermore if it's objective is to cater to generic thread pools then I
> think its an utter fail simply because it mandates strict cpu affinity,
> that basically requires you to write a work scheduler to balance work
> load etc.. Much easier is a simple unbounded thread pool that gets
> balanced by the regular scheduler.

The observation was that for most long running async jobs, most time
is spent sleeping instead of burning cpu cycles and long running ones
are relatively few compared to short ones so the strict affinity would
be more helpful.  That is the basis of whole design and why it has
scheduler callbacks to regulate concurrency instead of creating a
bunch of active workers and letting the scheduler take care of it.
Works wouldn't be competing for cpu cycles.

In short, the target workload is the current short works + long
running mostly sleeping async works, which cover most of worker pools
we have in kernel.  I thought about adding an unbound pool of workers
for cpu intensive works for completeness but I really couldn't find
much use for that.  If enough number of users would need something
like that, we can add an anonymous pool but for now I really don't see
the need to worry about that.

Thanks.

-- 
tejun