[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <521d9ec6-9aab-46d9-82e6-dab9c52970af@redhat.com>
Date: Fri, 14 Mar 2025 19:38:22 -0400
From: Waiman Long <llong@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>
Cc: linux-kernel@...r.kernel.org, Juri Lelli <juri.lelli@...hat.com>,
Vishal Chourasia <vishalc@...ux.ibm.com>,
Vineeth Reddy <vineethr@...ux.ibm.com>, Phil Auld <pauld@...hat.com>,
Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [PATCH v2] sched/isolation: Make use of more than one
housekeeping cpu
On 3/5/25 12:14 PM, Phil Auld wrote:
> On Tue, Mar 04, 2025 at 02:24:19PM +0100 Frederic Weisbecker wrote:
>> Le Tue, Feb 18, 2025 at 06:46:18PM +0000, Phil Auld a écrit :
>>> The exising code uses housekeeping_any_cpu() to select a cpu for
>>> a given housekeeping task. However, this often ends up calling
>>> cpumask_any_and() which is defined as cpumask_first_and() which has
>>> the effect of alyways using the first cpu among those available.
>>>
>>> The same applies when multiple NUMA nodes are involved. In that
>>> case the first cpu in the local node is chosen which does provide
>>> a bit of spreading but with multiple HK cpus per node the same
>>> issues arise.
>>>
>>> We have numerous cases where a single HK cpu just cannot keep up
>>> and the remote_tick warning fires. It also can lead to the other
>>> things (orchastration sw, HA keepalives etc) on the HK cpus getting
>>> starved which leads to other issues. In these cases we recommend
>>> increasing the number of HK cpus. But... that only helps the
>>> userspace tasks somewhat. It does not help the actual housekeeping
>>> part.
>>>
>>> Spread the HK work out by having housekeeping_any_cpu() and
>>> sched_numa_find_closest() use cpumask_any_and_distribute()
>>> instead of cpumask_any_and().
>>>
>>> Signed-off-by: Phil Auld <pauld@...hat.com>
>>> Reviewed-by: Waiman Long <longman@...hat.com>
>>> Cc: Peter Zijlstra <peterz@...radead.org>
>>> Cc: Juri Lelli <juri.lelli@...hat.com>
>>> Cc: Frederic Weisbecker <frederic@...nel.org>
>>> Cc: Waiman Long <longman@...hat.com>
>>> Cc: linux-kernel@...r.kernel.org
>>> Link: https://lore.kernel.org/lkml/20250211141437.GA349314@pauld.westford.csb/
>> Acked-by: Frederic Weisbecker <frederic@...nel.org>
>>
> Thanks Frederic!
>
> Anyone with commit powers willing to pick this up?
Is this patch eligible to be merged into sched/core for the current
cycle or will have to wait until the next one?
Thanks,
Longman
Powered by blists - more mailing lists