Message-ID: <YMtjvF0en9NjIspl@lorien.usersys.redhat.com>
Date:   Thu, 17 Jun 2021 11:01:16 -0400
From:   Phil Auld <pauld@...hat.com>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Valentin Schneider <valentin.schneider@....com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] sched/fair: Age the average idle time

Hi Mel,

On Wed, Jun 16, 2021 at 10:03:14AM +0100 Mel Gorman wrote:
> 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@...radead.org>
> > > 
> > > This is a partial forward-port of Peter Ziljstra's work first posted
> > > at https://lore.kernel.org/lkml/20180530142236.667774973@infradead.org/.
> > 
> > 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
>

Thanks for the links. It's cool to see what your results dashboard looks like.
It's really small, what are you plotting in those heat maps?

It's hard for me to publish the results that come from our testing (web based
on intranet) but we don't see any major differences with this patch.  There
are some gains here and there mostly balanced by some loses.  Overall it comes
out basically as a wash across our main performance test workload.

It'll be interesting to see if it effects a sensitive, proprietary perf test
suite from a European company with a 3 letter name :)


Cheers,
Phil

> 
> -- 
> Mel Gorman
> SUSE Labs
> 

-- 

Powered by blists - more mailing lists