[PATCH 0/4] Reduce scanning of runqueues in select_idle_sibling
Vincent Guittot
vincent.guittot at linaro.org
Thu Dec 10 03:00:49 EST 2020
On Wed, 9 Dec 2020 at 15:37, Mel Gorman <mgorman at techsingularity.net> wrote:
>
> On Tue, Dec 08, 2020 at 03:34:57PM +0000, Mel Gorman wrote:
> > Changelog since v1
> > o Drop single-pass patch (vincent)
> > o Scope variables used for SIS_AVG_CPU (dietmar)
> > o Remove redundant assignment (dietmar
> >
> > This reduces the amount of runqueue scanning in select_idle_sibling in
> > the worst case.
> >
> > Patch 1 removes SIS_AVG_CPU because it's unused.
> >
> > Patch 2 moves all SIS_PROP-related calculations under SIS_PROP
> >
> > Patch 3 improves the hit rate of p->recent_used_cpu to reduce the amount
> > of scanning. It should be relatively uncontroversial
> >
> > Patch 4 returns an idle candidate if one is found while scanning for a
> > free core.
> >
>
> Any other objections to the series? Vincent marked 1, 3 and 4 as
> reviewed. While patch 2 had some mild cosmetic concerns, I think the
> version and how it treats SIS_PROP is fine as it is to keep it
> functionally equivalent to !SIS_PROP and without adding too many
> SIS_PROP checks.
while testing your patchset and Aubrey one on top of tip, I'm facing
some perf regression on my arm64 numa system on hackbench and reaim.
The regression seems to comes from your patchset but i don't know
which patch in particular yet
hackbench -l 256000 -g 1
v5.10-rc7 + tip/sched/core 13,255(+/- 3.22%)
with your patchset 15.368(+/- 2.74) -15.9%
I'm also seeing perf regression on reaim but this one needs more
investigation before confirming
TBH, I was not expecting regressions. I'm running more test to find
which patch is the culprit
>
> --
> Mel Gorman
> SUSE Labs
More information about the linux-arm-kernel
mailing list