Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <b53de0da7c863ec4c883a92b2526a0f9132a24cb.camel@gmx.de>
Subject: Re: [PATCH 1/2] sched/fair: Couple wakee flips with heavy wakers
From:   Mike Galbraith <efault@gmx.de>
To:     Mel Gorman <mgorman@techsingularity.net>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Aubrey Li <aubrey.li@linux.intel.com>,
        Barry Song <song.bao.hua@hisilicon.com>,
        Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        LKML <linux-kernel@vger.kernel.org>
Date:   Tue, 26 Oct 2021 12:41:36 +0200
In-Reply-To: <4105fd08f84c60698b38efcb4d22e999de187d6e.camel@gmx.de>
References: <20211021145603.5313-1-mgorman@techsingularity.net>
         <20211021145603.5313-2-mgorman@techsingularity.net>
         <37d8c167df66a1ead16b699115548ca376494c0c.camel@gmx.de>
         <20211022110534.GJ3959@techsingularity.net>
         <496d495b290ac69fed75d02ab5915a7871243321.camel@gmx.de>
         <20211026081817.GM3959@techsingularity.net>
         <4105fd08f84c60698b38efcb4d22e999de187d6e.camel@gmx.de>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.0 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 2021-10-26 at 12:15 +0200, Mike Galbraith wrote:
>
...

Well now, that interruption didn't go as planned. The briefer edit
would have been preferred, but you get the drift, so moving on...

> > > It benefiting NUMA box
> > > hackbench is a valid indicator, but one that is IMO too disconnected
> > > from the real world to carry much weight.
> > >
> >
> > I think if it's not shown to be harmful to a realistic workload but he=
lps
> > an overloaded example then it should be ok. While excessive overload i=
s
> > rare in a realistic workload, it does happen. There are a few workload=
s
> > I've seen bugs for that were triggered when an excessive number of wor=
ker
> > threads get spawned and compete for CPU access which in turns leads mo=
re
> > worker threads get spawned. There are application workarounds for this
> > corner case but it still triggers bugs.
>

wake_wide()'s proper test environment is NUMA, not a desktop box, so
patchlet has yet to meet a real world load that qualifies as such.
That it could detect the test load doing nutty stuff like waking a
thread pool three times the size of the box is all well and good, but
not the point.

$.02 WRT poor abused hackbench: if it happens to benefit that's fine,
but I don't think it should ever be considered change validation.  It's
a useful tool, but the common massive overload use is just nuts IMO.

	-Mike