It would be nice to just create these threads on-demand,
and destroy them again after periods of dis-use.
Kind of like how Apache does worker threads.
Well, that's the same thread pool suggestion that Jeff came up with. And
I agree, that's a nicer long term solution (it's also how the per-bdi
flushing replacement works). The problem with that appears to be that
any suggested patchset for thread pools spiral into certain "but what
color should it be?!" death.
Let people complain with code :) libata has two basic needs in this area:
(1) specifying a thread count other than "1" or "nr-cpus"
(2) don't start unneeded threads / idle out unused threads
To be even more general,
libata needs a workqueue or thread pool that can
(a) scale up to nr-drives-that-use-pio threads, on demand
(b) scale down to zero threads, with lack of demand
That handles the worst case of each PIO-polling drive needing to sleep
(thus massively impacting latency, if any other PIO-polling drive must
wait for a free thread).
That also handles the best case of not needing any threads at all.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
