[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABk29NsXc6J_zM+WaZxdjLtx_NC6+86VpMrtXrGZZ4WoQ_PPvg@mail.gmail.com>
Date: Tue, 1 Mar 2022 16:41:57 -0800
From: Josh Don <joshdon@...gle.com>
To: Abel Wu <wuyun.abel@...edance.com>
Cc: Mel Gorman <mgorman@...e.de>, Ben Segall <bsegall@...gle.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] introduce sched-idle balancing
On Fri, Feb 25, 2022 at 5:36 AM Abel Wu <wuyun.abel@...edance.com> wrote:
[snip]
> > Also place the filter first and do any measurements of any change to
> > balancing versus the filter. I'm suggesting placing the filter first
> > because it's less controversial than a new balancer. Just be aware that
> > the filter alone is not a guarantee of merging as there have been a few
> > approaches to filtering and so far all of them had downsides on either cost
>
> Yes, understood. I will adjust the patches as you suggested and send v2
> together with more tests next week.
+1 to trying the filter rather than introducing a new balance path.
We've found the sched_idle_cpu() checks in the wakeup path to be
adequate in allowing non-idle tasks to fully consume cpu resources
(but that of course relies on wakeup balancing, and not periodic
balancing).
Please cc me on the next series.
Thanks,
Josh
Powered by blists - more mailing lists