From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A69273F54DA for ; Tue, 28 Apr 2026 10:53:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.165.32 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777373620; cv=fail; b=EsL3dWWm8o2k7zsxeKBWyDULrFySYlhMuwFhIP6lG0x+v1DNJe85XZyq3sDi0hHaKcBEWXe5hki9QQu/3e5RkoQxg/IuV3QTOZiXwRprRsVGFoNZKgUPh/RsQrCyqNlzUe2EXFztEqRQ28HNhzV+nYe44Dkmt+I+8agv4aYJFp0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777373620; c=relaxed/simple; bh=fv1aCg322rQxH94XCFXHogz+aUQg2Ls8htmpLK1Bcbw=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=iknfJScA+r5aizIpp73MJaj+rsFrDXSGGAFnfXt99TBnEfOjRyRsagWoowiynnHs2k5C04zd1LX/4KrR2ytpYzyValN5TYII/v+O/txnKioqaXm0K/CLIzV0eRvUrHFEFS7iRHj7r/FidCizjw7fJwnq5mbSn7LMVGYF7nuvAL0= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=oEgpMaog; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=AVUTzjdX; arc=fail smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="oEgpMaog"; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="AVUTzjdX" Received: from pps.filterd (m0333521.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 63S8JCS32128102; Tue, 28 Apr 2026 10:53:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=QLbubOYcVWD9fUQUiWp/h50akd1vlc+HGUolUut8u3w=; b= oEgpMaogJwOTH/c7b/OEWGZDp5fJkW6b7JBRX3ymg8/9Ujv91jOyBDmywRY+QUdp 84p5nhMcytq+nGrqCgZ/5GsGlo2WCCPARQTDAPq4vfiwN/Am8gsUmusW30geAiNW iXskKRiqt7/BIDvnbX6iJ1mj/oOSELktDyk01riyXczmn/UcCDp1Aw5YJbqx5EXc w9XMQOtUmdC9wuhSXC6jJGdC+VkMGohFdxYQbmUzfATR16IP1kg0xqEGWbnwHg1Z s08TfliXHZfv38RDjHZa7J37YzcfHUMtld6hidnnuSCQP1nYYe1BLTwcFDpyOIFZ HwNAWiSo2sUBEKyZ5jHcqA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4drmha7fqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2026 10:53:06 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7) with ESMTP id 63SAkwhs030799; Tue, 28 Apr 2026 10:53:05 GMT Received: from cy7pr03cu001.outbound.protection.outlook.com (mail-westcentralusazon11010067.outbound.protection.outlook.com [40.93.198.67]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 4drm2cbtft-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2026 10:53:05 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Fp5fdxossEHHdFBvRcIqa8ZT7266/72TqheuQhgcJzzEPRF5qiEGJsHtASxE5LuRvN8Y90L8eLcDv6gKCiT2ZsbhGDSsl0PiuJEERsoFUa9sb47NYOw4Vuoi5sh8fxCsKuLAOtaqKUWBrX0T9y7D4uuudeqsEP8XdauE5pJDyiQUQ/gMnUD0vVfQAS6h6s8RocPNvYXFfIY6ofz0oO/cl319IKK2BC9buGy2GtavLhE+0zarEaX/VmhWwdQvFJOQPoKcg6GmGVVWI/8kBuYjuH2KAXZHLN5SYsrBjUmFFbCr3v+c7pPNJus5UwauLe/DT6MKvm7pVIY+HDIEISGaJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QLbubOYcVWD9fUQUiWp/h50akd1vlc+HGUolUut8u3w=; b=rZl+EO5R+TnCbkpDkI8NZD6ndlu66FXSwyQ5vt7bQwOaviWjipgAbbqNSsKOZrljiPbCj9qsOFNVKkvnl04yIbsZaF5HlGMRRkFYFsfMHwr4zhoDdmdCGJ9fy8yc3IEHCINUK6Bw5ZbdDkmyjq/o3z6SXn0QYSJVfBoN/S7l+Ds4fHCMZeXHUjyT9pOmK8AjhcDUl5rnxmFOxb0mt7PXrYqsVPuyYFd1NGq79VWEa51RjX61FB9vnjYrtxWCBf45r4k+q98YKcHexQx0etLSAy28ZHGkwQv8zgNZ5r1f/P5GpYspuyH3CQed04Qzup2d+BaK5tx5bjlkt/9f0W1cWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QLbubOYcVWD9fUQUiWp/h50akd1vlc+HGUolUut8u3w=; b=AVUTzjdXdXea9Q4e/jSBm9zMg0ks2T1UM2GA8WV62lhf2HXRMxn3LkXC2K5RBq0GfWxsFTL5LMo6ZtDcPovm6KH+/2wM2zslfUSdtoByYPk4eCHGW3E0j3y1Z8RAxRCYb5hkTRBhmhCgiJnJhnY47F0QCirosZwLEiH6Wpkqm6s= Received: from CO1PR10MB4468.namprd10.prod.outlook.com (2603:10b6:303:6c::24) by SN7PR10MB6571.namprd10.prod.outlook.com (2603:10b6:806:2aa::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.26; Tue, 28 Apr 2026 10:53:01 +0000 Received: from CO1PR10MB4468.namprd10.prod.outlook.com ([fe80::f629:6f12:8d3c:3924]) by CO1PR10MB4468.namprd10.prod.outlook.com ([fe80::f629:6f12:8d3c:3924%4]) with mapi id 15.20.9846.025; Tue, 28 Apr 2026 10:53:01 +0000 Message-ID: Date: Tue, 28 Apr 2026 18:52:53 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] sched/fair: scale nohz.next_balance according to number of idle CPUs. To: Vincent Guittot Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org References: <20260421050622.19869-1-imran.f.khan@oracle.com> <20260421050622.19869-2-imran.f.khan@oracle.com> <610a00cc-e6be-42ab-9c70-e3f24d66e7a7@oracle.com> Content-Language: en-US From: imran.f.khan@oracle.com In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PH8PR02CA0040.namprd02.prod.outlook.com (2603:10b6:510:2da::17) To CO1PR10MB4468.namprd10.prod.outlook.com (2603:10b6:303:6c::24) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR10MB4468:EE_|SN7PR10MB6571:EE_ X-MS-Office365-Filtering-Correlation-Id: b91103a3-f8f2-4caf-cc85-08dea51450b7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024|18002099003|56012099003|22082099003; X-Microsoft-Antispam-Message-Info: /y65EnY4BY8Ft2zKQlRjXwoIpEl2Ez62XVi6sXJNKhQPjGPHLgYRTLxHrGjBjhGWlTbGVwB401flh1tpEoTmB7EQ55BzTSgUB/QxqEWOzIU2zqTPWTJrrRihzZBDhasIBRFoa1nIjfp5RVPszp1U5USOZkXSXrQisiuhNt+ItU5hFZOja6ISYeoEf437catMgHXeZYE5gldnU7GHJQH2f1Y5BWtGa24RhtUGRykGEBCDpJ5SeFungsVIw2HRLS7Zz5t2pOcs29kwjrPfiKLbzXIhTSZXk8oSkiGInTKqCEqRQLuhBiUQXf9IQqDPxpFYVN+985+j0ULPfKx/33qoIz8JOE1VECCFmdoc+2Tl58J4PS+x3ojw8pZ5m4agWZAKvaLS1vgSKrRrkLrFWxHqZ2vtF9AicAa2pj6Fp6pZSlx+vp+84xBidRSGKMqcsEfcK6uIrXBEye/zLJh0vmWsMdRSLfNRzKjPKYyBtfxqQ/GCuqE3sGz0nW+AT1yZB6nRRKRJ4aLh2mSR/7gUS2QHDkTeUVNpZrfxL8lnlugF/5vBUjXV61bK26J66UkXvEVTja/8kZwlD9QIc6kLXGSxqWI2GCwVpOV2Hrf084ktaWlBGj83WNFqJ9i3QLcAP5hzTMXgX6wJ6+DTRN5bX98nFY4LpDl7HKp/y+VeamCwWjt6rFlxpS5Vzm8miBGWXsHGJbkaD+MQiUkJuk8VrUmUryUVPhCacI4zqYVrlmWsPlw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR10MB4468.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(18002099003)(56012099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bk5HcjRiSEhTNW1HdGFkWHEwc0xYREFkd1h1YjlRaDFMMmFEKzFsUWpwMTl1?= =?utf-8?B?Sklqa25RVElHTDRlcC9aSGV1QjFIRGhvWjY5S1N4SnBIUGpxTmxTaVJ5TTBj?= =?utf-8?B?c2R4N3FJTXFReGNGM3pnOG1XRWYxVHIvNzFFV1FEdjlGYVdYLzZXbHkydk56?= =?utf-8?B?Y1ArMTI5SnFZTStENGRtTDZQejZpd2ZHMWxGRkxSOVUzNnZPcXkvTzFTZktp?= =?utf-8?B?M08zUnZFM2R2cWhGUU9kRDRZTllDSzV1b2ZUeDdwZlVjUkIyS1plSkxYMkJ2?= =?utf-8?B?UTVCNXIwR0FwdVVxNkdXOVhqRkk0Yi9Udm5qL2xjcWdEeUcwWStBQjFEa3BR?= =?utf-8?B?Q3ZISk15QW1wbTFmRGovUnZuODZPM0hDbExPWjA4d0w5T3loSlVCd2Zrc2ky?= =?utf-8?B?WTR4Y0hHS2k3TTlFODFvZ2NRM1p3OXJUK05yMitiaDhlNlZwUUw0Y1YzL2Fn?= =?utf-8?B?eUVYRTYwd2h2TVJWdGs4R05PQkJsTTloekkvOEZ2Z0w3QU5wbHVEcGxUck1S?= =?utf-8?B?K0hsWkN6MkpZUElzZzNuWXVlVzFHWkN0ZTUxUG1GbVFuT3JJVWM2Sy9QUmM0?= =?utf-8?B?SGllbXEvc3VIZi82TXpuNU9MNE0vV2J6bDFhK2NiQmdXSHFmeWFoTm43bGw2?= =?utf-8?B?MXBURUlGa21mUmc1K0JPbWFhbHo4cVRrY2FWUW1RU1hxRXNSdzZIYlpNQUJj?= =?utf-8?B?Y25uMlpnS1VyZWZRa2J1Q1A2VHBLSlFuYU9Pa1FiZlJncUt0SDFJOHczYTJB?= =?utf-8?B?enlja1VKNC9OUlQ3VUhwK2dTMlJCa0w1d1VFTkhmeXpkQVZPZllHcDc3elRH?= =?utf-8?B?UHIweHI3KzVOUnNyVkl2R3krR0VLY3VKRzBkb1padEQ2SUxzN1ZOdVBBZmRw?= =?utf-8?B?RElLOUVYajFIUXZ4WTVqbE1nWFRTM2s2NHZXUlROUGc5a3BFdmFid2x2Vi8v?= =?utf-8?B?R0hnOENJbTJwSXFRVzJENjA1a1N0WFlycTNWWkVFRHVRQWRTM3k3MlNYQmpF?= =?utf-8?B?MWxYUU8yWm5QN3E2ZWZLcG1RUitlRXF4QXVQS3FlNlVQSkFtb25zMUlyOUhn?= =?utf-8?B?T1NUdG1wajc4dStrZ1J0eGI2RzNtWlNhZjhyQ0dkcnI0UmZRZXM4M1Y4d1FB?= =?utf-8?B?SUN1Y3dKa1hRV2xGR3BTSFFDdFpGLytBa0JuQXpjR1pLdkZ3bHNVYlJjMDdO?= =?utf-8?B?SCtaQnU5dVpKU001bTlReHRnRTREWGFLNWNTc0l0VmNnUFBoR212REtuMFhn?= =?utf-8?B?RHYrRmFOSG5xZldYTGd4b05XK2VpK3kvcEhQdk8yWlZhV2l0OHUvRERsVERL?= =?utf-8?B?aktWT29nZnRCemE4M0VJUkM3bzZrVm1EdWdnZ0tsbG1DNzg0UUJ4OERFTlBS?= =?utf-8?B?aEl3TVZQZjljcVBiSTd1QmwwRjJ5R2U0WG5NNHpkb1hqWEJ1WHVXTGFrUWQy?= =?utf-8?B?WGcwZ0I0R1FNWnRYNGlkQVlGamxwNG1VdlJMS2JVeHhEdWYzMkZHY2EzdDNT?= =?utf-8?B?UkpsMnFIU3dBVHpORDlvbEFTdHV5ZlNJU2F1aHZ4YWJYVFNuaWwxSDlIemVV?= =?utf-8?B?U1Z2aXVPUVppYXZBb0c2U2t0Qit3cmIyOE9hMzF0Znd1NW9Vb1lDNlRocHg5?= =?utf-8?B?WXMvUW53cDQwaHFPbW1ya29iRmEzTnE4VWVSQ0Nrd1NsemxqZHpPWmZram95?= =?utf-8?B?alBkZXBsWGVZNi9IczQ3WUljTFdoenVLeEtRcGpYTURhSEM5TmxOQ2dPTXJk?= =?utf-8?B?Y1g1SGxzVWw4bVVKU2lPbEFLVExRYTA1VzNmdVI0Q0VBN0l3cDU3b05JWXpz?= =?utf-8?B?enNNN2tRVkxqMTQ0WU1VM2d4VXZJZ3J2MW41MGQvQmhkRGRncWdpZHdWbmFj?= =?utf-8?B?YnpBQWlsSS8zclNpcGlLU1ByeHpBdExDMFQvMDVDVUtFV000YmxhUmZ6dkJ5?= =?utf-8?B?L0hxdms4QUp3UXV4WDJTMlk1bkZpL0d1UGQ1U2pIb2xJMGJGNDhJbldmTjcy?= =?utf-8?B?VUFYTERSMEVBdWRWL1E5WmZtRGNLak9ZeXNpWm5qY0RteVNUd29ETFZ0VW1k?= =?utf-8?B?N01UdGR5S1AxcGVHS2JDTFVCbkhXSEZvRnI0SmMxTERyOVl4aFZLeGxsK1Nq?= =?utf-8?B?eWhxVm41YVZoRmhNcUZJdDJRN01mR0VJNjQ5ODV1QkNmeVB3YmJBN2JkQi9F?= =?utf-8?B?dS9KYytEWXUwTGZ1SXFOSzBoRERMT092Sm9wOVQrUlVIUk9jVTcrbzdFUjZU?= =?utf-8?B?bFNUejZLYm5oaVJzRk5pVHg3OVJvN2FKWEpzQTRjaDFQaFI3RVN4Zi92cmFF?= =?utf-8?B?ZkpYMk1YL2U4d2h2NU80RmszMnlMRGhRckhjSFczLzFBV2hnQjE1Nmd4emRV?= =?utf-8?Q?iX9+DSlERz4yA35s=3D?= X-Exchange-RoutingPolicyChecked: gi8570Mplm2gVsaiZq3rhv6SpIWR8nxRsWIMRPIGjkZVkyYNGPzA8M8ZznLFg+4eQYWKOKJu7wr5xVDgM0XEmcQTPBRDEyLXRl82xBx62UO76v5aCSBfRt6CLiP+BanPDvZYCxOw5XTm2FruPCdYjqT9FOf7F5gtoaEaMXYestnFxfdKEgCVXnmhL82Ddfa21myoJXjnJY0TYfWpEJWqZ1tdD1cEtYZq1Wuyb5Mj88+WW/yS98hhgft/hO+y6GA8N1Vpg/slIwytpdfSjrWw8UyDd9xSauGx9cDXBoDxVvTS55XGkeAH/Bp1Hi3R8eJJAiPNocW7a6j+t3ntWtmIZQ== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: HXX3QKf/lOckeJYuCG9a24TmQyOcPXS7J0jT4TpIVJnz4+WorXIKBVqMOAJmq0UtgxBAeN/BsatQF1ypX09FnU9e5iD+JkWKLLO4WqlIOs3y+0DQsCVZ60d1m2gkFoiDkKfzoJTrHbEOaGDnzXKundfKr0vh7ZekmKEYzZmMsHSP5gm2dRikPHI33dJdzfc8u0owYSVRY6D/WJkBejp6moVF15se2L/tT9kvHRHvdymhGWqqaPtwsT50jlpKovG/jVwOL+ZNTOr9VFMMf8i0y54mku464FcWWzDHSuHd2JHuRPODxKTbXwjL3X+ZRh4WxqDZ64IoLBJOo2NXyHQqLW1a7xiNEAJ9D4y/F1oKCSwyhlnACtrInlweuMMeKaGqq5oPPBVdbC963axDeqxYK/MlS/jMUXeidJ/f5hVsOAcpbJg0wNZwmjAlblWnnD8+zdOlp5bqjZTtsURg9RnocEQ4fajdKMTPJvghOOzYSDKJo62uc2sAEfg8trbm+VJmo47xUFB3n4kB/XE7St4h56gSIHcAL6mqp/ogJgBGzVKLLJNFlLsP+JjR+4kbY67Nlgf/Izis6D5iZxUSnfBnou3taj548dnpCJ9mhtiHFeU= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: b91103a3-f8f2-4caf-cc85-08dea51450b7 X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4468.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2026 10:53:00.9829 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mfphrpJ46g94h9CulrP42fXC2KOaQyPNTrloB71fiUUpCt31ZMlIe1E2AcWMmviBND9zzn0s+a9mIPcuwvS6rQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR10MB6571 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-04-28_02,2026-04-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2604200000 definitions=main-2604280097 X-Proofpoint-GUID: JvHOllyOCi1FsgK-qtCcHZK4svzxxcV8 X-Proofpoint-ORIG-GUID: JvHOllyOCi1FsgK-qtCcHZK4svzxxcV8 X-Authority-Analysis: v=2.4 cv=CrOPtH4D c=1 sm=1 tr=0 ts=69f09192 b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22 a=x0eKOSpe3m1H3M0S9YoZ:22 a=yPCof4ZbAAAA:8 a=Mw_Hthbn_ujfgRmjPKAA:9 a=QEXdDO2ut3YA:10 cc=ntf awl=host:13844 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDI4MDA5OCBTYWx0ZWRfX8sMb8RDO8GGp ZwosBcDiwEdbAhLtlXbct2+51+uKZcd4rmkUc4nTANIORHwLY+Oq+P6qubIlchRP2J6xJD6JCf6 PL8aJNrhrYTYHldMjxtsjOPfXL9uSXqtWxvklv1BD+lELpFYeTnHzbvXLue/FWoQDjeR9P7jH4D nlzYnPcKzYOmELgow+IcEGEJVTVreXzFTAvIMOEBeuelSinJT5D1wI3UkNGBRjjOMaRIPEwJzc1 PXd4Ue+1rATIkcTHnImkDawzrLXXqlAzAX8fy5+IbiAWAbsjhJ/CMxXpHoCtgfrgKP+IenXTlVN q/2U9VoUPQjDGqc+gN8uChmd553h9EMBMn1tp7i9662FoaRAQw6U8jPR7DTPTY/vPjKKkmXjVAr nL/nWCOnK30Ghf4SWrVy5JlKoT5XNmUr0rMZ8yG7occIZRJElCuKOWYPt4fwpK173Lq3wFc7s4H HwZP/AUHbpbz3ySL2P2w7zMR4DPh3a0Od+9g2fl4= Hello Vincent, Thanks so much for clarifying my queries. On 24/4/2026 5:46 pm, Vincent Guittot wrote: > On Wed, 22 Apr 2026 at 18:13, wrote: >> >> Hello Vincent, >> Thanks a lot for taking a look into this. >> On 22/4/2026 3:54 pm, Vincent Guittot wrote: >>> On Tue, 21 Apr 2026 at 07:06, Imran Khan wrote: >>>> >>>> On large scale systems, for example with 768 CPUs and cpusets consisting >>>> of 380+ CPUs, there may always be some idle CPU with it's rq->next_balance >>>> close to or same as now. >>>> This causes nohz.next_balance to be perpetually same as current jiffies and >>>> thus causing time based check in nohz_balancer_kick() to awlays fail. >>>> >>>> For example putting dtrace probe at nohz_balancer_kick, on such a system, >>>> we can see that nohz.next_balance is at current jiffy at almost each tick: >>>> >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770863 nohz.next_balance=9764770863 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770864 nohz.next_balance=9764770864 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770865 nohz.next_balance=9764770865 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770866 nohz.next_balance=9764770866 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770867 nohz.next_balance=9764770867 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770868 nohz.next_balance=9764770868 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770869 nohz.next_balance=9764770870 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770870 nohz.next_balance=9764770870 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770871 nohz.next_balance=9764770871 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770872 nohz.next_balance=9764770872 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770873 nohz.next_balance=9764770873 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770874 nohz.next_balance=9764770874 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770875 nohz.next_balance=9764770876 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770876 nohz.next_balance=9764770876 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770877 nohz.next_balance=9764770877 >>>> 447 9536 nohz_balancer_kick:entry jiffies=9764770878 nohz.next_balance=9764770878 >>>> >>>> On such system setting nohz.next_balance to next jiffy can cause kick_ilb() >>>> to run almost every tick and this in turn can consume a lot of CPU cycles in >>>> subsequenet nohz idle balancing. >>>> So set nohz.next_balance based on number of currently idle CPUs, such that >>>> for 32 idle CPUs nohz.next_balance is advanced further by 1 jiffy. >>>> This will nohz_balancer_kick to bail out early. >>>> >>>> Signed-off-by: Imran Khan >>>> --- >>>> kernel/sched/fair.c | 13 +++++++++++-- >>>> 1 file changed, 11 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>>> index ab4114712be74..bd35275a05b38 100644 >>>> --- a/kernel/sched/fair.c >>>> +++ b/kernel/sched/fair.c >>>> @@ -12447,8 +12447,17 @@ static void kick_ilb(unsigned int flags) >>>> * Increase nohz.next_balance only when if full ilb is triggered but >>>> * not if we only update stats. >>>> */ >>>> - if (flags & NOHZ_BALANCE_KICK) >>>> - nohz.next_balance = jiffies+1; >>> >>> This +1 only cheaply prevents multiple nohz_ilb from happening >>> simultaneously during the current jiffies. >>> >>> The actual update of nohz.next_balance is done in _nohz_idle_balance() >>> and reflects the next balance of all idle rqs. You should look at the >>> balance interval of your sched_domains. The min interva is the weight >>> of the sched_domain which can be 2 at SMT level >>> >> >> I did not look at the balance interval of the involved sched domain. >> IIUC once nohz.next_balance has been updated in _nohz_idle_balance(), >> we will see that updated value in nohz_balancer_kick() and if its further >> from current jiffies, the time_before(now, nohz.next_balance) test would >> cause nohz_balancer_kick() to bail out without updating flags and that in >> tune would avoid kick_ilb() path. > > yes > >> Since jiffies and nohz.next_balance were appearing close or same in >> nohz_balancer_kick() and I could see that CPU 2 was executing nohz_csd_func(), >> almost instantly and pretty much at frequency of each tick (dtrace snippet shown >> below), my conclusion was that one or more CPUs in sched domain of CPU 2 must >> have had their rq->next_balance close to or same as current jiffies. > > Yes > >> >> ts_ms = 1776868498610 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498611 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498612 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498613 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498614 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498615 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498616 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498617 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498618 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498619 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498620 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498621 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498622 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498623 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498624 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498625 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498626 rq_cpu = 2 nohz_flags = 3 >> ts_ms = 1776868498627 rq_cpu = 2 nohz_flags = 3 >> >> Could you please let me know if this understanding is incorrect ? > > yes, it is correct. > > The ILB is kicked for several reasons: > - NOHZ_BALANCE_KICK : periodic load balance based on the > balance_interval of each sched_domain > - NOHZ_STATS_KICK: update of statistics i.e. decaying the blocked load > - NOHZ_NEXT_KICK: loop on idle cpu to update nohz.next_balance when a > cpu becomes idle. > > NOHZ_NEXT_KICK and NOHZ_STATS_KICK can be set independently for > "cheap" idle load balance > > and NOHZ_STATS_KICK is set whenever NOHZ_BALANCE_KICK is set to take > advantage of the ILB to update the block load instead of kicking > anither one just for updating the stats. > > >> >> Regarding the question of sched_domain topology, this host >> has 768 CPUs and almost all (except 6) have been divided >> between 2 cpusets (one for each node). For example for node0 >> CPUs we have: >> >> # cat /sys/fs/cgroup/sellable-numa0/cpuset.cpus.partition >> root >> # cat /sys/fs/cgroup/sellable-numa0/cpuset.cpus.effective >> 2-191,386-575 >> >> and their sched_domains look like, as shown below: >> >> cpu2: >> domain0: cpus=2,386 >> domain1: cpus=2-15,386-399 >> domain2: cpus=2-191,386-575 >> cpu3: >> domain0: cpus=3,387 >> domain1: cpus=2-15,386-399 >> domain2: cpus=2-191,386-575 >> cpu4: >> domain0: cpus=4,388 >> domain1: cpus=2-15,386-399 >> domain2: cpus=2-191,386-575 >> ..... >> ..... >> >> Could you please suggest if updating rq->next_balance or >> final nohz.next_balance by some other logic can help reduce the >> CPU usage of _nohz_idle_balance or should we just ignore it >> because CPU is idle anyways. > > With SMT domain, the idle load balance will be kicked every 2 ms for > each core domain. If the load balance of all cores is not aligned on > the same tick, you will have an ILB every tick if there are activities > on some CPUs and we need to check whether it can be pulled on an idle > CPU. But it should be light > >> >> On these systems I can see that CPU 2 is doing most of this work. >> Running a perf top on CPU 2 gives numbers like: >> >> 21.69% [kernel] [k] __update_blocked_fair >> 11.40% [kernel] [k] update_load_avg >> 9.36% [kernel] [k] __update_load_avg_cfs_rq >> 8.07% [kernel] [k] update_rq_clock >> 7.09% [kernel] [k] __update_load_avg_se >> 4.67% [kernel] [k] update_irq_load_avg >> >> ..... >> ..... >> 22.26% [kernel] [k] __update_blocked_fair >> 10.89% [kernel] [k] update_load_avg >> 9.65% [kernel] [k] __update_load_avg_cfs_rq >> 7.80% [kernel] [k] update_rq_clock >> 7.23% [kernel] [k] __update_load_avg_se >> 4.76% [kernel] [k] update_sg_lb_stats >> >> and mpstat also shows softirq usage of around 20-25% on CPU 2 and >> most of that is due to SCHED_SOFTIRQ leading into >> _nohz_idle_balance. > > The time to update the blocked loads increases with the cgroup > hierarchy because we must to walk the hierarchy. > > Does it generate problems for your system? As you mentioned above, if > CPU2 is idle, running such background activities should not cause > harm. > No its not causing any issues. Should this mean that the second patch of this set can be dropped as well. I could see that despite multiple CPUs being idle in this domain, it was CPU 2 that was doing nohz idle balance most of the times. Thanks, Imran >> >> Thanks, >> Imran >> >> PS: I used the following dtrace snippets to get nohz_balancer_kick >> data shown earlier and nohz_csd_func() data shown in this message. >> >> dtrace -n 'fbt::nohz_balancer_kick:entry {printf("jiffies = %lu nohz.next_balance = %lu \n", `jiffies, `nohz.next_balance);}' >> >> >> >> fbt::nohz_csd_func:entry >> { >> this->rq = (struct rq *)arg0; >> this->rq_cpu = this->rq->cpu; >> this->rq_nohz_flags = this->rq->nohz_flags.counter; >> this->ts_ms = (unsigned long)(walltimestamp / 1000000); >> printf("ts_ms = %lu rq_cpu = %d nohz_flags = %d \n", this->ts_ms, this->rq_cpu, this->rq_nohz_flags); >> /*printf("[%lu] IPI received on cpu=%d\n", >> this->ts_ms, cpu);*/ >> /*@ipi_rate[cpu] = count();*/ >> } >> >>> Which kind of sched_domain topology do you have? >>> >>> >>>> + if (flags & NOHZ_BALANCE_KICK) { >>>> + unsigned int nr_idle = cpumask_weight(nohz.idle_cpus_mask); >>>> + >>>> + /* >>>> + * On large systems, there may always be some idle CPU(s) with >>>> + * rq->next_balance close to or at current time, thus causing >>>> + * frequent invocation of kick_ilb() from nohz_balancer_kick(). >>>> + * Adjust next_balance based on the number of idle CPUs. >>>> + */ >>>> + nohz.next_balance = jiffies + 1 + ((nr_idle > 32) ? ilog2(nr_idle) - 4 : 0); >>>> + } >>>> >>>> ilb_cpu = find_new_ilb(); >>>> if (ilb_cpu < 0) >>>> -- >>>> 2.34.1 >>>> >>