On Tue, Apr 15, 2014 at 05:58:08PM +0800, Lai Jiangshan wrote: > From 534f1df8a5a03427b0fc382150fbd34e05648a28 Mon Sep 17 00:00:00 2001 > From: Lai Jiangshan <[email protected]> > Date: Tue, 15 Apr 2014 17:52:19 +0800 > Subject: [PATCH] workqueue: allow changing attributions of ordered workqueue > > Allow changing ordered workqueue's cpumask > Allow changing ordered workqueue's nice value > Allow registering ordered workqueue to SYSFS > > Still disallow changing ordered workqueue's max_active which breaks ordered > guarantee > Still disallow changing ordered workqueue's no_numa which breaks ordered > guarantee > > Changing attributions will introduce new pwqs in a given workqueue, and > old implement doesn't have any solution to handle multi-pwqs on ordered > workqueues, > so changing attributions for ordered workqueues is disallowed. > > After I investigated several solutions which try to handle multi-pwqs on > ordered workqueues, > I found the solution which reuse max_active are the simplest. > In this solution, the new introduced pwq's max_active is kept as *ZERO* until > it become > the oldest pwq. Thus only one (the oldest) pwq is active, and ordered is > guarantee. > > This solution forces ordered on higher level while the non-reentrancy is also > forced. so we don't need to queue any work to its previous pool. And we > shouldn't > do it. we must disallow any work repeatedly requeues itself back-to-back > which keeps the oldest pwq stay and make newest(if have) pwq > starvation(non-active for ever). > > Build test only. > This patch depends on previous patch: > workqueue: add __WQ_FREEZING and remove POOL_FREEZING > > Frederic: > You can pick this patch to your updated patchset before > TJ apply it. > > Signed-off-by: Lai Jiangshan <[email protected]>
So IUUC this is to allow registering ordered workqueue as WQ_SYSFS? But I think we are going to follow Tejun's suggestion to have a low level cpumask which defines the limit for all unbound workqueues. This indeed tremendously simplifies everyting. I'll post the series soon. But maybe I'm missing other requirements that are fixed by your patch? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
