linux-kernel - Re: [PATCH V3 7/7] workqueue: Process extra works in rescuer when there are no more to rescue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJhGHyAc376ssH20vuRWjxX5gux0Ocm7efeK-DsC1w4k5A_fhw@mail.gmail.com>
Date: Sat, 22 Nov 2025 15:07:25 +0800
From: Lai Jiangshan <jiangshanlai@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: linux-kernel@...r.kernel.org, ying chen <yc1082463@...il.com>, 
	Lai Jiangshan <jiangshan.ljs@...group.com>
Subject: Re: [PATCH V3 7/7] workqueue: Process extra works in rescuer when
 there are no more to rescue

On Sat, Nov 22, 2025 at 3:29 AM Tejun Heo <tj@...nel.org> wrote:
>
> On Fri, Nov 21, 2025 at 10:57:20PM +0800, Lai Jiangshan wrote:
> > From: Lai Jiangshan <jiangshan.ljs@...group.com>
> >
> > Make the rescuer process more work on the last pwq when there are no
> > more to rescue for the whole workqueue to help the regular workers in
> > case it is a temporary relief and to reduce relapse.
> >
> > Also limit the number of extra works.
> >
> > Signed-off-by: Lai Jiangshan <jiangshan.ljs@...group.com>
>
> Is this based on some empirical case? Can you give a concrete example?
>

It is not a case observed in production, but it can be achieved by test.

If the pool is a PERCPU pool with concurrency enabled, having idle
workers does not necessarily mean memory pressure is relieved; it may
simply reflect regular workers waking up, completing work and going idle
due to concurrency.

In such a case, those working workers may later sleep again, the pool may
run out of idle workers, and it will need to allocate new one again, becoming
stalled and waiting for the rescuer. This can cause unnecessary delay,
especially if memory pressure was never resolved throughout.

Before patch 2/7, the rescuer processed all active work items
unconditionally, so this situation was less problematic.

But this patch does not really check if memory pressure is still on,
using (pool->flags & POOL_MANAGER_ACTIVE) can kind of
achieve it, though not precisely. There is never a precise way,
but the system has poured some resources to create the rescuer,
it is better to make the best use of it, like before patch 2/7.

this patch:
       if (!pwq->nr_active)
                return false;
       if (!need_to_create_worker(pool)) {
               if (limited || !list_empty(&pwq->wq->maydays))
                       return false;
       }

with memory pressure test via POOL_MANAGER_ACTIVE:

       if (!pwq->nr_active)
                return false;
       if (!need_to_create_worker(pool)) {
               if (limited || !(pool->flags & POOL_MANAGER_ACTIVE) ||
!list_empty(&pwq->wq->maydays))
                       return false;
       }

What do you think?

Thanks
Lai