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 929031A3164 for ; Wed, 22 Apr 2026 16:13:45 +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=1776874427; cv=fail; b=QRKEvJ7I7TDbQ5zybdTiebe74X9t1SxEK94L9XW9FLCOL0ceIOLQjmoDDI7dEwduLkTr0tM7wWC7t7oDI0aWsmeh/SbIRF3bsaTksmLXg7G/M0bqmRVjY+aOSaUnJnPmH5WIVxshTyb1dN0nonfJY11B9db1vPfjhFaH4OsOzME= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776874427; c=relaxed/simple; bh=+7dg70t+wwSGiDGBSmSQfNmW2KEdrIzL6vL8vLC8j0k=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=H4ix4+ElfW6PP/FgLFNWARFSguRwcI+duOgpyX5jGmuc+VAJ6/PWHR/j+mjfHvcpKlXoDO2iSl7G0/eSUqq5tTuBTWkxg7Ab+DFoPu5f8Od2mNyduij3vmb+EoRy6e4EkzGnHXgh39v/VqG8CoFtZmZMLKOkzazxv/moaa6qR64= 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=WSKvVHVg; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=t4+1H0F1; 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="WSKvVHVg"; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="t4+1H0F1" Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 63M9M7Ag2586138; Wed, 22 Apr 2026 16:13:14 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=40z8Qc9FJGVqs4Qn1XujtiwptDhB9oOfMbjLNu1w49A=; b= WSKvVHVg8RYW9MT3Y0sG4/1vy5tpp9T32t+SQdc4aoN9YDGgpZ0Mc+LQRrZ9FovI DSLsLw5qzNbhVpNQDgGYwn8L9m8qg7XO4trTDcTUhAV4NOAnk4aTGkyUUB1WTZIu 8GO+e59Lj8km/Ys7MI9N3YwmUDjVnEpKDMQZUDlK7cjNj3t61GQjKbc5HnfobNFv nAhOBi65beHE8Tz53XqFpwCXUrKFSMhoDOgTYrP6e0FL+qph41FNjT0UA/6BkM+p dK3T5WELh+/xTv5zOjkMLtMKLqAgWKimaWc/fiehHvBFPS3UKgH4imeOI1tbzjpx KJRUdAirJVtpWh9RzY9yEQ== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4dpenrhph5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2026 16:13:13 +0000 (GMT) Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.7/8.18.1.7) with ESMTP id 63MGBIqL000714; Wed, 22 Apr 2026 16:13:13 GMT Received: from sj2pr03cu001.outbound.protection.outlook.com (mail-westusazon11012056.outbound.protection.outlook.com [52.101.43.56]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 4dpjjexmjc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2026 16:13:13 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a8nxvkC0yLW9ZFUTANuuT+11kjqtRvfk5dI4P5akZTD5xhtGzjne7fM6EK53bRhGYPT3uFK/GZ7x8CZQ6mvHf5z5od9QFVFBPcnopLf3dWzviWQjpTNr6TH8LOLRI+ayLvLTMgT3q7zF3k6cBmyaWMOPzSFdrxhn/y0NBmrFeCEUu9tEFWEqUsal2T/LCFO89T1Gayli9Il3mSsEPQz+jdAVrxRxW6+UNXrjeFkVFHQ0KS9AiNQP4Q3KEE6aCSyQSKduRMfR/V77sjuL2MwaY4OSR9NZjRyyJR84iUcV6ZKljbkjzEBRBO395BfniOML0q5PtyhyWvovpvonI0B5tg== 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=40z8Qc9FJGVqs4Qn1XujtiwptDhB9oOfMbjLNu1w49A=; b=TSPlSQAlFqsAm+jxCF095pj/VaaWnmpDTr46JX7xd+JYJ2Yr11MrgAdSQuaGYOCzAk+txzl556VZjqL7erOGhylpWkRrIZJn9bCodZLKrNkt2dpcl+kkv7x91cOCz9gxiSeX4mLZEh82cdpb2AOzNi8jAM4/bPy1VhbmVGFwIuz1X/vNlg8FaSMgenGaoooHQ8jKiMgPBkGzmUcPmMfmOTQ7sav/XKD665QA+kK/U0RFvWODkhksu9io8pvO0sbeu4ORGL4Qu25VD2k29PYEw7HtqHAZsLYBq4JsEaxliCQm3NVXEw50tJRgxhMpjfbCvi/6HglO4w3l4OLNNkmILw== 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=40z8Qc9FJGVqs4Qn1XujtiwptDhB9oOfMbjLNu1w49A=; b=t4+1H0F145VvwLaJb/CPXJXWVwpGR0M9Mn+79UP9OaCz7RSsLmQqOsnV8BL9he5/WLcnM5cen3DzAGAY5EG/QgpHdPNSKrDESXEO3Fv2XBA+V7teZa2eu9EXeBtmEJfaqBMSX8+U1BZfZ0qWd+4GZ2aCTTQ066JL7yqN2zUEPrI= Received: from CO1PR10MB4468.namprd10.prod.outlook.com (2603:10b6:303:6c::24) by DS0PR10MB7455.namprd10.prod.outlook.com (2603:10b6:8:161::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.19; Wed, 22 Apr 2026 16:13:10 +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.019; Wed, 22 Apr 2026 16:13:10 +0000 Message-ID: <610a00cc-e6be-42ab-9c70-e3f24d66e7a7@oracle.com> Date: Thu, 23 Apr 2026 00:13:03 +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> 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: PH8P221CA0050.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:346::11) 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_|DS0PR10MB7455:EE_ X-MS-Office365-Filtering-Correlation-Id: e0c70d6d-8019-486f-5e2b-08dea08a0c16 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: 2L+MZ/k2RybWjg0QprZACJ/l9q9YUgn+2KnxUSJPSo8zdRNkM3JjemLAmYBaRFbWvm/CQ1+D6OFhomDiO5wbirLwR3yN0O2zOzDNeyvjOdOOQugAmubGMU/oblAFJxutQYxrMI7U/4xvmyAZauiE8xpHmAraabt9agamxhxpoO7ZYKUJwgI9un28uxVE5XbeLeK19ZBdTpsB9bCtdYb8i1zHmvT8jA0Ql4dxE8Q7ctqJkhJqEN7jkyEArR8RjlpnRI0KbO2oBBkkA8i+BiMmovQunA4Gde76e3NUgkzu5+e0/2UqjOJB8w/tBIgADFRemH7/uPuKaFhb394yRtpEqQ46RCNcDLEKgIk0V/KFXKlYFFwlunivbg16GG4Ysqv89Fbgvm44W17OelilGHOSpLxv5Q3PI9+L7b1DUbkL4UaDoAUfC/QLLwMOSUrus1Pwq2xISEa/mNY5jdnSFBEEW9HzST8k8I4D/mv9TOqKyFlRUfbvr/z/R0cCwg8JTepdITzkjg+2bpN3n230YfLNrk+8QkTIBmCmVqzAJX5EgT6oeL/7Jdkvu01F4k7HkxgXODtydjsLgU2uZn/OBeM9q6oT8qHoekuXNfM08DTPC4YzEEZGdR9BIMIjQlBBCuIGZorzOT/yScQHx+wptmms7XCQD5QrhMbbFRpPXRR7whYVN0cmfWvxmCpBbx5NSpcBI/PY19am3kDgMbY7KVYmuVBIMXBd2ViqxozR4hotqGw= 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)(376014)(7416014)(1800799024)(366016)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TU13RmpCR1NGSW5qVXluOHFDZUhNd0x4U2hRQUs2ZThoMW9UWnkvL3h5OTRz?= =?utf-8?B?MEdGa0JiV2NwRDlwblJpazFydmU3aDhsNysvOWJLaWt4T3lzSXUwMWF1NTll?= =?utf-8?B?ZDZ0ZHl0cmdlOTF3eDBpMmpBaHBCMXdaWndrWEpiZ2RhYURGOGpubTdpZWpl?= =?utf-8?B?Q3ZyK1Jlbi9mM0hvNHJXUjBqWURZZHYrM2NWU1JWWFhOZVg3QTdVVHBCYnp6?= =?utf-8?B?ZnpTelE5dmFvRDErZE51djQ3Q21Pc1VBczhyTnhrMGw5d1plWkEzMisweGFS?= =?utf-8?B?YU5yNGNoWkpMZDFsblVkY3ZrS1lLSExjM1dPZ1JsRVU1MkdSL0pMZ0ZVMGxY?= =?utf-8?B?UTZpMTNUbHdoYWU1VzFHSjVUdWh2dVlMRG8wTHVVRVFwNTVRVDBHRU1ZTksw?= =?utf-8?B?SmJ1cnVLTkNDbWNMVmdqSEpWeVBnL2xxcWJNRjhzUkJFa2xGcXQwZmd2OWd4?= =?utf-8?B?dG1mMFRlZERTS1lYT3RlcWJidUlxdWd0TFgyM0RKNnNkYUpQZWZxWjVOaWZK?= =?utf-8?B?ZG5ITGZVTGRhbEhTTkhuNGhyOWYydk51cm81ZXFzV1RVVjcvUmJIVEtpbDFr?= =?utf-8?B?ckVpWWxGQjhFcnVVdTRTQWdZQjlpOTRDVnVxUHU5a0xiZlVNZDhxV3EzK0tr?= =?utf-8?B?QmF2d2lmeldEOGcxakswZlF1TTl6c0F5TWgzekI3OTJpQ01uMC81MDkxcXNG?= =?utf-8?B?QWJYdi9TMk9TQ2ZCYkxKNW9meCsxb1JteUNHK2UvVUlvMTBYb0p0TnlBR3hY?= =?utf-8?B?VjFjVmt5SnhZdlkzeEpWUmNBN2cwRzFHSUVDRWsrNVh6NGZPa1ovb3VkRFY3?= =?utf-8?B?d2liTXZaNTc4REZPdm1HU1c1OW5xUWlVdnhIRE5wYWQ4SkF5a1NJNEdWMjk2?= =?utf-8?B?cG16dFJaR3lhcGdXZzVVMmVIUENGbzJGSjQ4WmFRK0VRbG5IWDh1WmJmbWVY?= =?utf-8?B?eG1iczJOVHFjcEJ1ZVBsbGNVTlRucmFGMnB3QUpvTlZmcEhISzc3cmNNTTkv?= =?utf-8?B?UEpNTUcyNWMzazBwNjZoaCtGV2p1aHBpVnpoNnZPWDVJNFpUUnU1NDFpRlUy?= =?utf-8?B?ZHhFQXZsVDV2NnJLTkV0TGtHSE9IMkU3Z242eUxXMTcxdW1HZ3hzdVYwTWF2?= =?utf-8?B?SExseVpjcXBKbEx2bWpGN1lrZjdjbjBXVmdUM0NOL3NKVUljczF0alJPaFVW?= =?utf-8?B?cGJBL09TVVZnMGUxaFpwblhvUGQwYmlHUy9pQmxlSE8zS1lQNzJ4NFZtR3RP?= =?utf-8?B?TVV3K09zaHpudVBqbERKalk2SE5ZNk1RV1FUOTgvOVBQclVyN3RvU3YvclFQ?= =?utf-8?B?WHNSTlNjNWJWczUrNERHVHdTUXJHNjAxS0tiOExuYTJKUHBMMy9QUm1ib0RZ?= =?utf-8?B?amRVQWtBZ1g3TkVRZzI4K2tQSVZBOW5QVmVubmZrM1lQazMzeW1nMWhrQ1oy?= =?utf-8?B?d1dScVVoOFFpL1VOSWdDeU00bTRlN0lIanBmQy9xK3ZVZHVPSEpkcUx2dXYy?= =?utf-8?B?R3V6Y256SG5DWUprZDBtbEtZNU9rRkk5dmdQbVlIY0xoS05yMHA2eTkwczl6?= =?utf-8?B?SGs3OTR3WTh5UzVhS2NSa3FPUkFTMWlEcXl3bXQ2TUc5TTFZb041bVZQakda?= =?utf-8?B?YkFVSW1VK3hCVjBTK1JSdThqNjJmY1FxRzdwclZuanBsRVJJNjk1enJGSHhs?= =?utf-8?B?KzZaUXNjbEtqVE8xNGFOazF0UWpnSVRqQlg4R29xakVlL2FsbVgvUDgvdUI1?= =?utf-8?B?OHhyQXUwbzRHdTNEMm9teWc0UVc4YlVielI3akZYNDNOOU11OEJsYTMvUFZi?= =?utf-8?B?SlA3L1J2aGpHc2lHUmdoRFJEWmFCZGwxa0NNNkpDRFdCS0lKdmwzd2VMOTdB?= =?utf-8?B?TnlDZWJpSmhmVXMrUGhYcTF1VW5QMFptQ2hvM3VoWEhKTUIrY09ZV3pHNzlt?= =?utf-8?B?YzhVU0VnMXJoaHRBUlJ3SkRMamw4ekpZSXVITzJtZENrZVVUeENoQWpZbk1N?= =?utf-8?B?MkhwazhWaWZhcTNST3VmT3JyQ01wNU5JOS9KajJkTWZWTVo3RkJVZEtzV25w?= =?utf-8?B?U3JKYnlFdEhJb1FPN0lhUlp0M0VTeGxlc21GWW5JN0lkQXVrRnpMZW5kUW04?= =?utf-8?B?WjFyRWFubWt2MEI4dng3VDlvcStjckllV1hTREtpOUMzKzNnV3lyNFZqZnpu?= =?utf-8?B?UXl2VW1FRWF2dTd2Z3RVV0xwSmNBWGMvTlhuVU5kSlo0ekVhTTZQZ090dTJC?= =?utf-8?B?R0doMUk1dVhWSkVaQ3o5RnBYNUJPM0QxY0htYVFkSVAwOENUUjdhL1BZNkJE?= =?utf-8?B?aDdseXNmQVZ0TVNYQTF4U1k5NnlIRW00bE1ISVR0d3hpZXRzbWJnQT09?= X-Exchange-RoutingPolicyChecked: vRToHmGdZcQDdK88IQRJB87K7Rw/CfWWOMInxpVz812j+SCVZHjjHyC9dtiEPBs0dNoJ2uv2ZZK5+GHSgvUKBlPvRZaet+pUfJnK3tVZbPcdgk9SEjkXP+dMc/eW0qhQ/vXU3OAxE90Pyr723iG9hOJ/sBJDO5WtENo0BLSc1d36pyZ5eL/1mt1UI3Q6yQeKt1gFBdiv8CmhuDjpA8vOHubJmwVKF4jArINl4wzd3gruQQa01nZq8oX2sXzBBUCjkFlCAGci/qJ8M0LPq7x2cobWO7yCW9QP74FzQOT3uaE52l5AGXXE+D9RePovy9fMkuoelJNsGE5gumiIOYW1LA== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: uIVsPOJAkSqktV3tFYc2N1dbdMnVYBE1QqJ3TVMWWwXkNCFppTQwsEhPHRYxjKZu0dsHcnha5v82JRkl49Mg1EIoP50uuOhop6OQI/bFbOz6LSxzNIiW7GUTbNTol2qD9JoBYUlkNrZPrUYtOvbrrzTaj+XXkXHcyDzVFhI27lO0wdYYTwyVzK5NbhrGcygGlLxTeEmGShKB1ulfp+vRuLbbVk3oO5zZMK+ULCP+mDhm3bcdyxM3yByq+DNAARXyK9JVVmnLeKzYzTRkRb3Ah0hlHdEPsVDRgN7L0m7I0RkE3apllLuIY+Zm6n/DDnMYuh+7AVGBUh4DR+uWdbA5IpDMQkJteiowr5uWrMTMBAVocx+BGUdgvYT7YGVc4XNsR4TXWtXNgh49Njg5H1XwgqQmrseuHE+QAh053WrutUQui2H4GCsO3Of7J9AYVcIolCT5ob+iafNrWZO2kCMa7dEdjG6y6y/eLNttZHUwe9j6/fbySB6pWYYR4yTpjMU6OWMkT0TSP8NMFQITRfVl07VyJApmmco0P5u/jAkxmbfoX1hSHMhaqXdaaanV+6qedGf4NQV+SkP1yHZBu4uZL+F6wGYue/tl73e9n1sCspw= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0c70d6d-8019-486f-5e2b-08dea08a0c16 X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4468.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2026 16:13:10.5106 (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: tklOzW91jnYih7WMpFwB3CbV2JFHLmPFgO3TIXF5GRPvI56GtjQ4Xn8aKkP/uZgK9hRX0SnI3Z3lFBQdxtIJmA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB7455 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-22_01,2026-04-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 mlxscore=0 phishscore=0 suspectscore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2604200000 definitions=main-2604220157 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDIyMDE1NyBTYWx0ZWRfX4E513qoQgyeR nAnDXFiEdoIV9OWusYq2UJBwwtqQrk1NVonrrCF4AHqRPDE+D15d/tFGyqaoRTchFV0Az7Y3z1T 6pY+7NNSlnVf4WoTDkl/8vLQgFbHUcZuCrfsizI4QQE+2hpzcz+mk+vn2OCDFvshXqvuPEFi+Pi 5nLc3DZhrsuJjPcqlUgT17AE0R779Z5oYvDcirhcv4sMr4/1vmEY+FmGr6afyf4LBEGH9FCkQDa 7641LsxrDurNres0Zfm0+TSMfjwf3GI2vxHzG2bUErhHmLkD8mEYiKBoAB7LvL2Qh3H5ZudonLL JYKaSYzulQ26/XAYPF2a/VeqtzVBo098YszdY/L9+aYSSd3RcH2Wpgqt8w3iSaNkZguLaB6nisQ qA8p+g6uR3g6aFt/P5FQugX1/lxbOe6D8Al1z9BXCNz/pUUZVsGuOxxKKQP39h+w6AeGZAi0+nB 9/+kzkvUM7kQnWjepDQ== X-Proofpoint-GUID: tIitIMLBLRDKEVX0bDFBROAEGOnU1u3M X-Proofpoint-ORIG-GUID: tIitIMLBLRDKEVX0bDFBROAEGOnU1u3M X-Authority-Analysis: v=2.4 cv=JeKMa0KV c=1 sm=1 tr=0 ts=69e8f39a b=1 cx=c_pps a=WeWmnZmh0fydH62SvGsd2A==:117 a=WeWmnZmh0fydH62SvGsd2A==: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=RD47p0oAkeU5bO7t-o6f:22 a=yPCof4ZbAAAA:8 a=eG8eerx2FfoMZJcF8hoA:9 a=QEXdDO2ut3YA:10 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. 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. 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 ? 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. 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. 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 >>