Messages in this thread | | | Date | Wed, 19 Aug 2009 17:15:10 +0100 | From | Alan Cox <> | Subject | Re: [PATCH] libata: use single threaded work queue |
| |
> Are work threads per workqueue? Combined with per-cpu binding, > dynamic thread pool per workqueue can get quite messy. All three > factors end up getting multiplied - ie. #cpus * pool_size which can be > enlarged by the same work hopping around * #workqueues.
Stop a moment. Exactly how many work queue users need per cpu binding wizardry ?
> Another problem is that if we apply this to the existing default > workqueue which is used by many different supposed-to-be-short works > in essentially batch mode, we might end up enlarging cache footprint > by scheduling unnecessarily many threads, which, in tight situations, > might show up as small but noticeable performance regression.
Only if you make the default assumed max wait time for the work too low - its a tunable behaviour in fact.
Alan
| |