[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKfTPtBU44JP0FjhT+X1D+j=iAs0n2AObd5sMYJu+si0SYMftA@mail.gmail.com>
Date: Fri, 4 Jul 2025 17:46:52 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Chris Mason <clm@...a.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Chris Mason <clm@...com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] sched/fair: bump sd->max_newidle_lb_cost when newidle
balance fails
value to
On Fri, 27 Jun 2025 at 15:32, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
>
> On Thu, 26 Jun 2025 at 16:55, Chris Mason <clm@...a.com> wrote:
> >
> > On 6/26/25 10:26 AM, Vincent Guittot wrote:
> > > On Thu, 26 Jun 2025 at 12:58, Chris Mason <clm@...a.com> wrote:
> >
> > >> Got it, I'll play with that. Vincent, was there a benchmark I can use
> > >> to see if I've regressed the case you were focused on?
> > >
> > > It's not a public benchmark but I had some unitary tests with tasks
> > > waiting on a busy CPU while other CPUs become idle for a "long" time
> > > (but still less than 500us in average). This is even more true with
> > > frequency scaling which will minimize the idle duration by decreasing
> > > the frequency
> >
> > Ok, I don't think I'll be able to reliably recreate that on my own, can
> > I ask you to rerun against the v2 I sent out?
>
> Yes, I will run some tests
I ran some tests and I haven't seen any differences with or without
this patch so it looks good for me.
I thought that you were bumping the max_newidle_lb_cost to
sysctl_sched_migration_cost when newly idle failed to pull task but in
fact you increase the actual cost which is ok
Acked-by: Vincent Guittot <vincent.guittot@...aro.org>
>
> Vincent
>
> >
> > -chris
Powered by blists - more mailing lists