Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 16 May 2023 19:32:37 +0800
From:   Aaron Lu <aaron.lu@intel.com>
To:     Chen Yu <yu.c.chen@intel.com>
CC:     Daniel Jordan <daniel.m.jordan@oracle.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        "Ingo Molnar" <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        "Vincent Guittot" <vincent.guittot@linaro.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        "Daniel Bristot de Oliveira" <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Tim Chen <tim.c.chen@intel.com>,
        Nitin Tekchandani <nitin.tekchandani@intel.com>,
        Waiman Long <longman@redhat.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] sched/fair: Make tg->load_avg per node
Message-ID: <20230516113237.GA1943@ziqianlu-desk2>
References: <76939bf6-1d9d-5f8f-f15c-f03b2322d684@arm.com>
 <20230329135455.GA108864@ziqianlu-desk2>
 <20230330174557.m6jsgb6hsni4mxwq@parnassus.localdomain>
 <20230412120736.GD628377@hirez.programming.kicks-ass.net>
 <20230420205201.36fphk5g3aolryjh@parnassus.localdomain>
 <20230421150559.GA162558@ziqianlu-desk2>
 <dfkllxtzchrxeqykzyk24ppgwxbztk6rbbb6xyizpbhg7ctibi@fhk77qxo7yia>
 <20230504102746.GA137823@ziqianlu-desk2>
 <20230516075011.GA780@ziqianlu-desk2>
 <ZGNFkDkyipat5J8v@chenyu5-mobl1>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZGNFkDkyipat5J8v@chenyu5-mobl1>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+TBd0Uv6PHzOGm1wGRSo38e0jpbJ3aqMWeTj8MeQ2MY7fhnEenVXJzweOONc?=
 =?us-ascii?Q?VttXrSVy97jiQQ7UbJ/odXcGGmUCkBQ+2F2iAwVHpXNIlAiNWYUA1a45O2PU?=
 =?us-ascii?Q?almx7RtzZ8czX4DO6KVSLYSziikJqG3eyvtWVCr8Qexx7fgTh8xJSBrQIOaW?=
 =?us-ascii?Q?k1b8JkGPK3jZfS8k8GKqsbwxo8JkdYLlM+9pm+1o9wNpsz4suSqmQeCBljIq?=
 =?us-ascii?Q?CA3eiEwFwkY8LW19pNAHAf1uJTjBBdZLzHeYiXp3MCuYJy+K/lGcnXzis7sI?=
 =?us-ascii?Q?9HwJdMct2Zd805okLxDjcfVtXiwz7+6spN5kLFC0a3DLzmwAc4qHMTRNwPL5?=
 =?us-ascii?Q?pjrhce8w+pQEz4xkYlmec0cehvCz9szr2Gr+zeISh+IA28fajjDkgyR0QIYL?=
 =?us-ascii?Q?zSgj/rYgG/BKEZh4iSaWQr3d2xYhqPz4SW0X/PGv9LevLAneN7rYy+cbc6f+?=
 =?us-ascii?Q?M5jx2GCUJQ3XazSq3O4rZ1HacU+aT+m22aUFmv1+JauwvU+8HyWTVPrFJymI?=
 =?us-ascii?Q?385FByyrk5buc0P7hXE6j/cZ3uSjOS75MsN7I77RrbwjjCrNmhYmwUEADMis?=
 =?us-ascii?Q?7yATI7vqof7T1ET0+VlCeRuTJwTHlKh4T5QGPnFTI8syLpBKb7/UYP4W6msU?=
 =?us-ascii?Q?ubAuLcBdpItABHrSmBoE7v6DSQQfcVvTlXaSx2wRH3wd3NPNqTJV4DCAEfMD?=
 =?us-ascii?Q?/PCBNTfmz/sJJAwPt8yFnPzO4uQp525T3xxk8AsguHKANNRR8kc84OYQz7fP?=
 =?us-ascii?Q?Zf56x4bh7uGD1r6f0pwSDELdqLjdNsnGVryHPc/BW/F2YBz5uQh3cqkwB30o?=
 =?us-ascii?Q?UYezbRYDQFYsQE11DXUnbi1TPS/s1EkiB3b6syVQ4qF9HhGTEXezcIJ1YGU0?=
 =?us-ascii?Q?IwJgKhrQTfq7So7zkEPJhjJ2SDDJUAOcZQT/BScPf+MqRCw2Q1nRnVV33bJa?=
 =?us-ascii?Q?ijGunI/HGVkYMJfQXYVcTT8iUcd0aW1uXvzIlZm0/5vgP1fq1r6asLQjybwn?=
 =?us-ascii?Q?WpMuyQP4jeRktjr8Sfz54cPu8b/IdtmVfkQL1alCmKE0f6N/+qFiCCkOSvph?=
 =?us-ascii?Q?nGJcJUuiCpXV4T5XVq586s9eWTG6lkqQkaXW8Rat1UxGdVfuePFbNu3uQSIc?=
 =?us-ascii?Q?ysUPNJVw0V2H1GLY/nL4AUP5PBlMj4b0lmVB6bsmwt2W6DDx0taa7eoBthK3?=
 =?us-ascii?Q?oow2rJhcmrZwzMEyEiQbECpigbdXqUpp68MQOLEEYyOO96Bcc6ZQWyLvT9ub?=
 =?us-ascii?Q?gOBMJQFrGeSxf4M4hgTASGf6dg2JGJIY2yfHR3y2rAgHNZqujt48fRfxBCeH?=
 =?us-ascii?Q?1RUhm2vEJ9LYVl09vtEgFqHYXtttdg5jQryj9AWd3MGSlzA+MELiMuoXsOE6?=
 =?us-ascii?Q?DhGPyNnAAw1pho/emuxMkgyF0R+HO6MWRpcgdw16CBKSYnIKZejEegegcJ0w?=
 =?us-ascii?Q?mjIjHmbVvXkgT7pmBlBh4sImvNcBkzxrFAbBR1UtzbqBxiTR5Tv7shmnYV4U?=
 =?us-ascii?Q?0Ezm6rXcp301zqAOu/2P9bCZqyi8ooC17kX9FgWmZWyKZPCs5liuYWv/INu4?=
 =?us-ascii?Q?tp440WtNasecGQyNyzQ4FWoyINwT6dowgQuuUP9C?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cacc16b-5ff4-4df8-cdac-08db5601470e
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3062.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2023 11:32:49.1926
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7LQIu1Iybs3pA3QzlAqHvDkIdJGzMrolVf1tGtp6ADoeYKoqOmEHh1s0CIa6+v05633E0gF4eduxKYYoILeojQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7449
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, May 16, 2023 at 04:57:52PM +0800, Chen Yu wrote:
> On 2023-05-16 at 15:50:11 +0800, Aaron Lu wrote:
> > On Thu, May 04, 2023 at 06:27:46PM +0800, Aaron Lu wrote:
> > > Base on my current understanding, the summary is:
> > > - Running this workload with nr_thread=224 on SPR, the ingress queue
> > >   will overflow and that will slow things down. This patch helps
> > >   performance mainly because it transform the "many cpus accessing the
> > >   same cacheline" scenario to "many cpus accessing two cachelines" and
> > >   that can reduce the likelyhood of ingress queue overflow and thus,
> > >   helps performance;
> > > - On Icelake with high nr_threads but not too high that would cause
> > >   100% cpu utilization, the two functions' cost will drop a little but
> > >   performance did not improve(it actually regressed a little);
> > > - On SPR when there is no ingress queue overflow, it's similar to
> > >   Icelake: the two functions' cost will drop but performance did not
> > >   improve.
> > 
> > More results when running hackbench and netperf on Sapphire Rapids as
> > well as on 2 sockets Icelake and 2 sockets Cascade Lake.
> > 
> > The summary is:
> > - on SPR, hackbench time reduced ~8% and netperf(UDP_RR/nr_thread=100%)
> >   performance increased ~50%;
> > - on Icelake, performance regressed about 1%-2% for postgres_sysbench
> >   and hackbench, netperf has no performance change;
> > - on Cascade Lake, netperf/UDP_RR/nr_thread=50% sees performance drop
> >   ~3%; others have no performance change.
> > 
> > Together with results kindly collected by Daniel, it looks this patch
> > helps most for SPR while for other machines, it either is flat or
> > regressed 1%-3% for some workloads. With these results, I'm thinking an
> > alternative solution to reduce the cost of accessing tg->load_avg.
> > 
> > There are two main reasons to access tg->load_avg. One is driven by
> > pelt decay, which has a fixed frequency and is not a concern; the other
> > is by enqueue_entity/dequeue_entity triggered by task migration. The
> > number of migrations can be unbound so the access to tg->load_avg can
> > be huge due to this. This frequent task migration is the problem for
> > tg->load_avg. One thing I noticed is, on task migration, the load is
> > carried from the old per-cpu cfs_rq to the new per-cpu cfs_rq. While
> > the cfs_rq's load_avg and tg_load_avg_contrib should change accordingly
> > to reflect this so that its corresponding sched entity can get a correct
> > weight, the task group's load_avg should stay unchanged. So instead of
> > removing a delta to tg->load_avg by src cfs_rq and then increasing the
> > same delta to tg->load_avg by target cfs_rq, the two updates to tg's
> > load_avg could be avoided. With this change, the update to tg->load_avg
> > will be greatly reduced and the problem should be solved and it is
> > likely to be a win for most machines/workloads. Not sure if I understand
> > this correctly? I'm going to persue a solution based on this, feel free
> > to let me know if you see anything wrong here, thanks.
> Sound good, but maybe I understand it incorrectly, if the task has been dequeued
> for a long time, and not enqueued yet, since we do not update
> the tg->load_avg, will it be out-of-date? Or do you mean the task migration
> is a frequent sleep-wakeup sequence?

When a task is dequeued due to it's blocked, then its load will not be
subtracted from its cfs_rq. That part of the load on cfs_rq will decay
and tg->load_avg will be updated when needed. Because decay happens in a
fixed frequency, that's not a concern.

When the task finally woke and was appointed a new cpu, then its load
will have to be removed from its original cfs_rq and added to its
new cfs_rq and that may trigger two updates to tg->load_avg depending on
how large the task's load is and the cfs_rq's current load contrib to
tg etc. and that is where I'm looking for some optimization, like the
migration will affect corresponding cfs_rq's load_avg but it shouldn't
affect tg->load_avg so there is no need to subtract task's load_avg from
tg->load_avg by original cfs_rq and then add it back by new cfs_rq. But
I suppose there are some details to sort out.

Thanks,
Aaron