> 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 -- 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
