Re: [PATCH v2] sched/fair: Age the average idle time

[Mel Gorman]

On Tue, Jun 15, 2021 at 10:42:28PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 15, 2021 at 12:16:11PM +0100, Mel Gorman wrote:
> > From: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > 
> > This is a partial forward-port of Peter Ziljstra's work first posted
> > at https://lore.kernel.org/lkml/20180530142236.667774973@xxxxxxxxxxxxx/.
> 
> It's patches 2 and 3 together, right?
> 

Patches 2, 3, 9 and 10. I saw limited value to preserving the feature
flag. Some of the series has since been obsoleted. The main patch of
interest that was dropped was patch 1 because the results were somewhat
inconclusive but leaning towards being an overall loss.

> > His Signed-off has been removed because it is modified but will be restored
> > if he says it's still ok.
> 
> I suppose the SoB will auto-magically re-appear if I apply it :-)
> 

Yep, it would and it would indicate that you didn't object to the copying
at least :P

> > The patch potentially matters when a socket was multiple LLCs as the
> > maximum search depth is lower. However, some of the test results were
> > suspiciously good (e.g. specjbb2005 gaining 50% on a Zen1 machine) and
> > other results were not dramatically different to other mcahines.
> > 
> > Given the nature of the patch, Peter's full series is not being forward
> > ported as each part should stand on its own. Preferably they would be
> > merged at different times to reduce the risk of false bisections.
> 
> I'm tempted to give it a go.. anyone object?

Thanks, so far no serious objection :)

The latest results as I see them have been copied to
https://beta.suse.com/private/mgorman/melt/v5.13-rc5/3-perf-test/sched/sched-avgidle-v1r6/html/dashboard.html
They will move from here if the patch is accepted to 5-assembly replacing
3-perf-test. This naming is part of my workflow for evaluating topic
branches separetly and then putting them together for another round
of testing.

NAS shows small differences but NAS would see limited impact from the
patch. Specjbb shows small losses and some minor gains which is unfortunate
but the workload tends to see small gains and losses all the time.
redis is a mixed bag but has some wins. hackbench is the main benefit
because it's wakeup intensive and tends to overload machines where deep
searches hurt.

There are other results in there if you feel like digging around
such as sched-core tested with no processes getting tagged with prctl
https://beta.suse.com/private/mgorman/melt/v5.13-rc5/5-assembly/sched/sched-schedcore-v1r2/html/dashboard.html


-- 
Mel Gorman
SUSE Labs