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 16:57:52 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Aaron Lu <aaron.lu@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: <ZGNFkDkyipat5J8v@chenyu5-mobl1>
References: <20230328125624.GA6130@ziqianlu-desk2>
 <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>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230516075011.GA780@ziqianlu-desk2>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HWqiG/XMknzT/xQl69NBCZOMeAAZhx74N+b3FA821kl+bU5jTVTweYSrktAH?=
 =?us-ascii?Q?YPGfV5fYBjBx7nfxNO5g6Q0Of6zeqpM+i/vgPJVn5R4YhZkOqGCwMa5r8x4g?=
 =?us-ascii?Q?1nXH0vk4G5L20Pypwu8jBK4YrgAIIiemig+L4tPgSDtH5uEMQDF1xpOmupFf?=
 =?us-ascii?Q?f4997Hb0Skjco7vqbEEHlmRjUcLoeUn2GBZJgrdrisRjMn3gmj86x1wmloXw?=
 =?us-ascii?Q?MjMq0hSpa7JxnMowTBzwDFh5C2cl3tWWDsN3oBs7ahSzP1PwljRO/kXy0ECs?=
 =?us-ascii?Q?r7922gEYJXY8GZFhoEEyCX+4wCyCfeYTK+UzXHQqC+hb91LnRB7wNURFs4w6?=
 =?us-ascii?Q?rPhcUw5m5MQA9TDhb9xizLeL2k5zPX1ZVtwL77qLZGKl1lSl2Yp7D4Fq5dKp?=
 =?us-ascii?Q?zUivD39R5398Q3NRgUb/zmrUhkepGr2GL1pDJf+89r0so+GnoJMd9WW//r3J?=
 =?us-ascii?Q?SAExWFbbv6FGT6gMTJf2A+LACa58RRuCyS05FY9Jx5i9kBEiKrM+kprLjzkM?=
 =?us-ascii?Q?AgUgzsymVtY/69j89BA1t7PN6hj3DmnEcVQoWaho2Ve6L300wt0rGCOfCPzH?=
 =?us-ascii?Q?qGHArb8ZLMfHTQd3m5sRHGy3MldBUgLSP5mWPnORtMLaZTyjv0rPN6WbuAzc?=
 =?us-ascii?Q?aVyNxZUPJESnW7CU1NP2zNBSKLQFCmLuRGcrHoxVcKIKt6Egzuf83grkVrDp?=
 =?us-ascii?Q?R0mFX/WRE0hxP5fOv2WhHDlErATw4gKXPamRsi7nN9Me/fZkQAWJje7sFjiP?=
 =?us-ascii?Q?/E5WzEDqRWNH1AkC3wggES9KhGy63VG+8wuMEQKjU+1hZHuh/PKUVyGuT0n9?=
 =?us-ascii?Q?XsK0ZWIfB2nm9WSpLjAjFiJn2v29ixK4VsRkRHhDSvjonlizPAOmB4ddNB3L?=
 =?us-ascii?Q?FCeeLehyJs8EHARWRdrbJJvc1HeiDL8clfJ99u0pBP0X/OUPUm2/R7x59u84?=
 =?us-ascii?Q?7TzVVt1YytBc3xloQHzALQsOwziZbNtoMGntNjY8r/uSKW/0/0a3CcQMf+Zs?=
 =?us-ascii?Q?w/2XzFfmjgqgr8Nqe4agHM/gP+9ngZ1p7P1TT4hrSjmAsDLDvsXg+dKhWZGK?=
 =?us-ascii?Q?f8mXZxXNxhUbQDKJ0I9UE34R4stcdisu7uEU6UCvFhawiof9B6VNl+stZqaT?=
 =?us-ascii?Q?8Jk51Vzh2tSr7oX4Rx3vO5oTy7xG/T04LoYyR4SzK+pOLYT/OeKpkorUL5Uo?=
 =?us-ascii?Q?nXaBnHkqD/QFP7Cvg/9UiQVYRnveHhwsNGu/+GOoFhe9dNx3R708Krahtgd6?=
 =?us-ascii?Q?3A803sRk4g2TJUSXgjrCppQsgOet/AV/iQM/BwKlWzu7WvphXa+0beaHJ+rz?=
 =?us-ascii?Q?b3o6zyf1lSNsjo+54R7V8pE7MB9R6TR5ZAwO+09H3YrAqq6KuavwuvyXpCBA?=
 =?us-ascii?Q?WVuup6aFLA47dWJ5d7Talyfv1ZctYM462BxW9ermBbyKtD4VxIz8tyTG3IDF?=
 =?us-ascii?Q?6GdAsLuG44wcKFDQFnQwpg5RUNWxv9kRz08jhU26Fcrz/kHyyE9EE8zQyVIo?=
 =?us-ascii?Q?ytMEPWNslPLaldF5lkrgqR0xTHh3UlLxJ8t4zdqg7+C+hFhpA8HIg7RKZv4v?=
 =?us-ascii?Q?TDu0DSciZgfYxx4fS6PQqCfpK3GvQ0KruqtY55CJ?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1836d6d9-deeb-4dad-a946-08db55ebab99
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2023 08:58:08.9892
 (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: I+9G6k2mrt+gnbzkhty/nFFERf7zlM/RERmw5tXYwXWnE7FIxerhx8puVv1W1HFPUk8FqQuVpL60BXop8jsrQw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4973
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,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 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?

thanks,
Chenyu