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:   Mon, 27 Mar 2023 22:45:56 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Aaron Lu <aaron.lu@intel.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        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: <ZCGsJB36YYbgsgBW@chenyu5-mobl1>
References: <20230327053955.GA570404@ziqianlu-desk2>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230327053955.GA570404@ziqianlu-desk2>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HdXogpDKYhdW3/fwCo3zdTIBDHQw1xvjZlESbgq8UQOZ3UfXiNLXtxZXPVfF?=
 =?us-ascii?Q?zbpyZkBJwO4xJk09lll/GzDoOWMtUnmPpdUD3tXTBK/m/E5XvwHm/L5A01yb?=
 =?us-ascii?Q?Ogzjk8pm6c3lWyq46xhYl2LnSXS45jgviizPP4z2PZVI2Lm3Sx8cJhTc6CDR?=
 =?us-ascii?Q?ec/bMqm1ZMlI+sXJBNvI+g1pMoI080e1KCpqcvj1dr3i0XTa6WFd3/tfj+fW?=
 =?us-ascii?Q?h/1Fjvv9b8VuCzeGqyrKZQnEJwM0wd9py9YYvDJJf+ZqmlXzE467YaTm99i4?=
 =?us-ascii?Q?Ziq2ZEjG6k9upsTycGvqQd8Zqq1LXpGfGhAQLotQC/eGXQuvVv+toQ30fUDL?=
 =?us-ascii?Q?UJiNoruVsezLSIjmXLERvW5+ekXhhQ06tnG+HfNp3MZ5oWuJOf413DMu/asR?=
 =?us-ascii?Q?1t+ybjS7QdvBJr1onM1SrpbYzhoy6cG7gEFkq0XJ6sCpju6UF4QjFF4yNPB3?=
 =?us-ascii?Q?pnCsXL8xGlIFGZLRJMwDf0kAbiYgIs9DinBRfTCaqXClWp8kVmrxgTOvYBkO?=
 =?us-ascii?Q?2WjbylCs6NOgAd4z5qw2n6MVx7vqb2ef19DeJjEbEN7LOu6rRgAZl6f3MVY7?=
 =?us-ascii?Q?f3QkBWpV7TyszYDdIqBS/WqyAdOndMhX59A9SfgRgi1H7PBkF8lWlhWbbBxL?=
 =?us-ascii?Q?ScORboTFzZeggdIyYexJvqyr553sw/hXyefX8hanrh+kudVsw6Bj4Xc6LfII?=
 =?us-ascii?Q?OYSoF/W+u/IMUEBGip/Iveo6yCfUTVRGoC164p896NJyC9vsADNdxKpYhYIy?=
 =?us-ascii?Q?OMr5SIMhiJQVQ3g4bgq97GsRvbWiICNX6rcsjjgYcSazTsdorXUJT93nbFui?=
 =?us-ascii?Q?Kkf63iluPyBAYkwklfFwETmdFaEBegAW/wtrqVXldBibOiV8SHWli8I0WTzG?=
 =?us-ascii?Q?93SABscISZSTujrkCDpx64ItE/pBIxYfU8psxJ9nbsNHlRPEqe7eqrDWUGDp?=
 =?us-ascii?Q?C4IxSCZnCpGhDer4bKrX+eZNyGtYTekeS4kBXJu4xio7A6bHs+WX/Z4D64VO?=
 =?us-ascii?Q?gTzDkD0EFuGLcnJNTyscUfUaGyCPfbE6EIXU5DR6JBJe+PREqrsS5txgx5Sn?=
 =?us-ascii?Q?OfTTFUfgBFLXpUMFsUx/oja6Z/mFR3t5Zr63cDIYw7nxsMky2EmaOnyrU2oY?=
 =?us-ascii?Q?IGq9jcHILCj4evOAELyNgA/snBOEPJvClXWpQI6iNjwItqZSmbSe8BhJjigQ?=
 =?us-ascii?Q?cVA7ehMGkU8HL40OAZB28JW8UQdy+xl9WNrqkYqapwIQ988gQRur7Pg+wYcp?=
 =?us-ascii?Q?Kn+vLYf9oSP5+qMklumA/cUrdXtcP7aqQQ21DjT5LQOizZAkVljTABd7wCjN?=
 =?us-ascii?Q?VEcv2d6YEYgFF7kGauNjT+eeL7j86wQavMyFuiM/1mcdaQ2mpxPGleHSvIj1?=
 =?us-ascii?Q?6bxG9Fqrnu/Fb8FO+xgHWmtF8C+0rQ+XANeMFlqi3gcPhbMcnR4rXWc0/Xzk?=
 =?us-ascii?Q?q9c5EbyRSw/v0gJIw0AFMP7uXDPNrDaWI6LOY9R5eGptWzYxlqV3o12ZG5f3?=
 =?us-ascii?Q?qsleVYkizYyi5aPa5ifcf+Bi8xry1lVo3/wSvv6rkx8evl2L68GOrNvifeHs?=
 =?us-ascii?Q?/oAMVkhpEYM6b2p78FS+qVORXbEWI5je4ekyJ0Dx?=
X-MS-Exchange-CrossTenant-Network-Message-Id: ff7eedfc-07fe-4c62-d3e9-08db2ed20384
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2023 14:46:14.1822
 (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: iqvHomUABEwB3q78IW1917rVZOLpUTYWcwcyWtKTgihHxs+5HL+q2ZW9+Rfl/IYgL+/W0Hx+cQaQRChMeZV0qQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7862
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=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
        autolearn=unavailable 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-03-27 at 13:39:55 +0800, Aaron Lu wrote:
> When using sysbench to benchmark Postgres in a single docker instance
> with sysbench's nr_threads set to nr_cpu, it is observed there are times
> update_cfs_group() and update_load_avg() shows noticeable overhead on
> cpus of one node of a 2sockets/112core/224cpu Intel Sapphire Rapids:
> 
>     10.01%     9.86%  [kernel.vmlinux]        [k] update_cfs_group
>      7.84%     7.43%  [kernel.vmlinux]        [k] update_load_avg
> 
> While cpus of the other node normally sees a lower cycle percent:
> 
>      4.46%     4.36%  [kernel.vmlinux]        [k] update_cfs_group
>      4.02%     3.40%  [kernel.vmlinux]        [k] update_load_avg
> 
> Annotate shows the cycles are mostly spent on accessing tg->load_avg
> with update_load_avg() being the write side and update_cfs_group() being
> the read side.
> 
> The reason why only cpus of one node has bigger overhead is: task_group
> is allocated on demand from a slab and whichever cpu happens to do the
> allocation, the allocated tg will be located on that node and accessing
> to tg->load_avg will have a lower cost for cpus on the same node and
> a higer cost for cpus of the remote node.
> 
> Tim Chen told me that PeterZ once mentioned a way to solve a similar
> problem by making a counter per node so do the same for tg->load_avg.
> After this change, the worst number I saw during a 5 minutes run from
> both nodes are:
> 
>      2.77%     2.11%  [kernel.vmlinux]        [k] update_load_avg
>      2.72%     2.59%  [kernel.vmlinux]        [k] update_cfs_group
> 
> Another observation of this workload is: it has a lot of wakeup time
> task migrations and that is the reason why update_load_avg() and
> update_cfs_group() shows noticeable cost. Running this workload in N
> instances setup where N >= 2 with sysbench's nr_threads set to 1/N nr_cpu,
> task migrations on wake up time are greatly reduced and the overhead from
> the two above mentioned functions also dropped a lot. It's not clear to
> me why running in multiple instances can reduce task migrations on
> wakeup path yet.
>
Looks interesting, when the sysbench is 1 instance and nr_threads = nr_cpu,
and when the launches more than 1 instance of sysbench, while nr_threads set
to 1/N * nr_cpu, do both cases have similar CPU utilization? Currently the
task wakeup inhibits migration wakeup if the system is overloaded.
[...]
>  struct task_group *sched_create_group(struct task_group *parent)
>  {
> +	size_t size = sizeof(struct task_group);
> +	int __maybe_unused i, nodes;
>  	struct task_group *tg;
>  
> -	tg = kmem_cache_alloc(task_group_cache, GFP_KERNEL | __GFP_ZERO);
> +#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
> +	nodes = num_possible_nodes();
> +	size += nodes * sizeof(void *);
> +	tg = kzalloc(size, GFP_KERNEL);
> +	if (!tg)
> +		return ERR_PTR(-ENOMEM);
> +
> +	for_each_node(i) {
> +		tg->node_info[i] = kzalloc_node(sizeof(struct tg_node_info), GFP_KERNEL, i);
> +		if (!tg->node_info[i])
> +			return ERR_PTR(-ENOMEM);
Do we need to free tg above in case of memory leak?

thanks,
Chenyu