Re: [RFC][PATCH] create workqueue threads only when needed

[Peter Zijlstra]

On Mon, 2009-02-02 at 20:46 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2009-02-02 at 10:14 +0100, Oliver Neukum wrote:
> > Am Monday 02 February 2009 10:05:28 schrieb Benjamin Herrenschmidt:
> > > > Work which /may/ sleep longer, for example performs SCSI transactions,
> > > > needs to go into a private workqueue or other kind of context.
> > > 
> > > Well, it's a bit silly to allocate a private workqueue with all it's
> > > associated per CPU kernel threads for something as rare as resetting
> > > your eth NIC ... or even SCSI error handling in fact.
> > 
> > How do you avoid a deadlock if SCSI error handling doesn't use
> > a dedicated workqueue?
> 
> Something such as slow-work or async funcs (not sure about the later, I
> have to look at the implementation) but the basic idea is to have a pool
> of threads for "generic" delayed work, when its busy, pick another one,
> and the pool itself should resize if there's too much pressure.

One thing that comes to mind is that some people want strict cpu
affinity for their work, while others want the work to be freely
scheduled so that the load-balancer can get the most out of the system.

I think mason does something like that in btrfs, where he has likes to
keep all cpus busy doing checksumming or something or other.

One could of course layer these things so that the principal thread
pools are per-cpu and then let the next layer RR the work between all
cpus.

Furthermore, all cpus seems like too wide a mask, imagine what happens
on a 4k cpu system, do we really want a cpu half the world away from the
IO node doing checksumming? -- is there a nice solution?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/