From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (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 034B848AE0F for ; Wed, 29 Jul 2026 13:48:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.7 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785332924; cv=fail; b=XgwFczFgsKXdsur53em4CslBwrpO24F25nlSBpRmH4yiHdTZR+oF9Sf+OE22EFZwpWtxxerWjVQTsaaUnp2x+LUZtYj9kJnYuNUfqhPh8nN9CFqQf/9U/4zZEgLe1UBl7q1WKg8YYh3V+V/8/aAIMLPlj7ha2+y5hkof6JVpAfg= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785332924; c=relaxed/simple; bh=bX9ZgNPh0q/hnGDOtxz08Wd32F5AAe83PytPGoduDW0=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=CH1SYTeCsOyRTsp+1vyusaGSaUH1QFlMoOXx57AIf3hWYlxtmZ3uITvvQaUM3bJjp2z67tDH3OPSi/loPghftYJ7R72nl7Ty7i7sJ9ogQ8WwwQgvYF0VT5822H5Qn+0LlWdlBXIxoWSJfXyDalLKxK1y1Zvgutl4MW4jadcCTDQ= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ggFiR+v8; arc=fail smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ggFiR+v8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785332919; x=1816868919; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=bX9ZgNPh0q/hnGDOtxz08Wd32F5AAe83PytPGoduDW0=; b=ggFiR+v8BXh31pqYKf4g87VP/kuGaMnGF6+khSCNAzel5hY3EtmgWagm wjCq2wxaT42olZa8UuKKHkpbb5RsmXuOxgvOWRTxCfJaP9H6RJCU6vb6U qGcayrI0wYwhh4sH4678ANQapS0cImlrm/OQILzGzosuSRnZwBXQIrBoz x0aMlHB+1sybM20QWZqiVK8aY4MMv6FU8VGSLjwo9n/nNwPPBrIPTWQWB 3MV18+NVJNlVn/O42P86rgiMPr5kwNWOH7baP4wq5TbLVbjFLtocGX7Zg z4437FhvoMuWXooi5Ti0edBqDrL6AHNleJs1Hd3p5tl6lnPVCWTEaYSq8 Q==; X-CSE-ConnectionGUID: mGv76lO1SKOQVidLpLvi8A== X-CSE-MsgGUID: 4Z0DAtM/SdqIAY+gf+SDVA== X-IronPort-AV: E=McAfee;i="6800,10657,11859"; a="111482198" X-IronPort-AV: E=Sophos;i="6.25,192,1779174000"; d="scan'208";a="111482198" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2026 06:48:33 -0700 X-CSE-ConnectionGUID: kwuIXe8DSVSX1Z3tS2arFA== X-CSE-MsgGUID: 3+A8ozCETQC4hDYq3YMa/w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,192,1779174000"; d="scan'208";a="260068029" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2026 06:48:33 -0700 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 29 Jul 2026 06:48:32 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45 via Frontend Transport; Wed, 29 Jul 2026 06:48:32 -0700 Received: from MW6PR02CU001.outbound.protection.outlook.com (52.101.48.33) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 29 Jul 2026 06:48:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=INBF6/CZtz3zlBjJg6yrfijht0A/2JMT7SA2ueX6LEFChrPA9mznlWzqQSo7Ma/QM6/tL6cwJO1cQdS7fsxb+oY93o/u4mlVt+mdTI+2lzRx8hqPATgafrl9DFFvYFYzyONj7IeyPTBnPAHs2n3TKzrfw7btZ9j3Z5/xpIstSHgqh93cHo34lxAIYfy+cWphUhXWA2cCxFuDSmsMVpP9EMKMw922mEL6+lsl8llq70eAv46KWDH26F31M0mMxqw0RHgQuU77FlJySr5LM9matpB4YhHZPQnLk0fwyc2kBVa+3hmpj7Tp9KE/xs3EJoHibXlPVZWUCT1DtNnhSrQyhw== 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=uMkavcGYCpXdDz86hGSHWA9ZUhcqEXjR6BZBYOYyo9U=; b=o/O6MBrxHmFe7JS6hvU8CWF1pMNUjqlggBRtQyrl2265ecsSBOtsqD6DQFlv99HQ0Adozxh5IPe4OCa53Me0cEQjNTvI4UVDe0kad1ynhGKlnjoBZCO6PHmXa+Vy7bDbZL4XGRWmbJCDKE+4VinQWcWYX0GUGUb4iKBhHPp7ANVH+CDzZKbzu4JkbwUud0rUS0jhjoJPplbuPppETiGy7RswvvNgFn9RuH7lyKYiAghaGsk/YpsZHIBOSQhWzx+UHFH2kQMoHqbwICsBjt+miYa9wRNWWuzfMH1tREt9NCfqvHMkpZujiKcP2idu/V4VinqtCgzCnuLr5V+IsbdIPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) by BN9PR11MB5260.namprd11.prod.outlook.com (2603:10b6:408:135::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.12; Wed, 29 Jul 2026 13:48:30 +0000 Received: from DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765]) by DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765%4]) with mapi id 15.21.0270.009; Wed, 29 Jul 2026 13:48:30 +0000 Message-ID: <81e3a13f-6f08-414d-aa29-86fb022aac49@intel.com> Date: Wed, 29 Jul 2026 21:48:19 +0800 User-Agent: Mozilla Thunderbird Subject: Re: : [PATCH v8 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus To: Luo Gengkun CC: , , , , , , , , , , , , Chen Yu References: <20260723040429.630176-1-luogengkun2@huawei.com> <20260723040429.630176-2-luogengkun2@huawei.com> <1dc03c84-9bc2-4db1-bab4-3f603fba54cd@huawei.com> <8b7cd508-3b89-4fc0-85fd-5a8d35ed06ca@huawei.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <8b7cd508-3b89-4fc0-85fd-5a8d35ed06ca@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI3PR02CA0013.apcprd02.prod.outlook.com (2603:1096:4:295::10) To DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) 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: DM4PR11MB6020:EE_|BN9PR11MB5260:EE_ X-MS-Office365-Filtering-Correlation-Id: 293ad04b-2f07-4a5b-8d21-08deed78128f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|23010399003|11063799006|4143699003|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: CNcDq9v6ZQZHffpmiVdIMh5So9Up1WWQ4Xwkvn0nBwF4F5HNIewnSJTrOwQ4JxeojQOmcFDH22pikPehnHSQZGkTR9crYkS8jnTkXsPAccGWz/XXbl4tpiOLjBNra0sgT1zvnlCn/K4bRXxY+lP52pMzkLvi+79HFtjPSyzkTzt2q/Hh5qOZA+m8lCoYjdwT6BQDq60chH/p7Q5ibRQFQWVgDXS9wCQRu01tQOmYlcJddAKJHxij5vWOg9naeXfVvzHtxRmJ2WHfgf/1N9McbVn0NjEzYtqwvRczx0BINtXoU1e+t0mYMCl7wO/pAhh3yYb5NkqDBNPpLok35R2ScaB9JvEMrvDgRl9ChfA6+NqKfTGvwHoJ5+5LgZCAfMYmuS6ro1x20XY2rvZXCyk0WqZMlD0RkDIizrIThlrtzJ6j3n9B/3IhfZt0ZpvoHtslYaIYO27BizDG+Ueoek2c7KbRPn3K25s6+eE3YJOgSXkKJU5URRRubsY+N1BHmh1TMgqSa7DW3qIbwixiWMBzjkIcEUsegE6vndqHQIeDqu5n931ikifOe1qt3SpYy/8Nkng9qQcXvnnY0j/iAhWFe5EbT91gKjH1tNdeWKSpW4b0oq/Y2DhUpKllCSJE/iFQVx6cB0iDX19AE+BH1t7PASqixRmcRHDz1YcNVv7SMKw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB6020.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(23010399003)(11063799006)(4143699003)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RFQ4ckhNbjQySXRocEN2WDV5UVducXhWaEl0UW9SY0E3eFN3a2N0RytVQWp5?= =?utf-8?B?blBsV3pFT0FQOEtOUW5qNTM0V0haZ1dZWUhMMGs1eXRaOWtSUWRCRm96ZElm?= =?utf-8?B?SjlJZVdzV1hrOVlER1FjcjA0UTNDcmFmSG5Qb3FTeXNGNzF3U3JncXRwZnJF?= =?utf-8?B?b1BpTkVRQm42aThDZjFhNEVBbmZoMnpveG45Z1A0MTM5Um9vVkt3Z2ZuZEtB?= =?utf-8?B?TEtrSzV2a3g5NHBLZ2lhWFNRS2lzMFVOMkdkeXpVV0xXeS9nUERLZGtXMmZP?= =?utf-8?B?a01QNzZSTmxWb1RkTnZHR0RUYk5qMVBQNCtWQzRSaDViS3dDUzhTMytOdHZF?= =?utf-8?B?N0dra3A4ZmV5dzY1YnlzeWtVZEQrN21wM2ZuTUVsZUsvVlh6WGJLUmhRb2gy?= =?utf-8?B?MWNOdHNxT1U3NWNmYklkTmwvWHlYc3NNVThjZUFsR043S0JMcWdoRGQrK2sx?= =?utf-8?B?czZydGdPMVZlaU44SFdBYlNkb002a1lEVDR0bVU1S0FRY2FtN3NoS0NUakU4?= =?utf-8?B?VjZuQWZDSmlWTUxNb1c4cWNFMW0rWks0Ky9TM0FnWDRONEdCbTVEMldYbFRz?= =?utf-8?B?cU1NRmdNVGY0d3h5Y1lwUEwzdjRJNzA1QWFreDJnR1pidVZqKzN3RVJPMDF3?= =?utf-8?B?TEdWVmZRakVzZFNqL282d3d0Y1EzK09wNEg3VDFjZmxxWGpSempkMlByS05B?= =?utf-8?B?YXg0ZmVYZlJ3dUVNdEh2NG5uenBIKytaQm1vNXRMYys5UnQ4VHVkeU9FdW1l?= =?utf-8?B?djlDWW5lVHEwUnVtcnphb2hPQW9tRmdRWGRHSDFURWh4WXlOL1hYMjVTU041?= =?utf-8?B?Y0JxSFMrL2krWkJ0ZlcxVzNFa3kvZzBvNktaejQrUlVLVzEvLzhoYkVBRUE5?= =?utf-8?B?OWJEOGhMNzcxbjl2S21pTmMydXA2blFzWDVFc1VVRTJzcWg2d053M0x6UGhV?= =?utf-8?B?ZE5ObzVRMjVRczZUbTN1NFpQSTkySlJsdnhIOEhyZjI0SUtLa1dJbzR0aVNJ?= =?utf-8?B?b3NjZ1dVcXpOOEltcEFFSlEvZ2tpMWhQRUR4K2NBWnRBTll2WmIwazRQVCs1?= =?utf-8?B?RkI0dUFaWkxkVE5VY0NpNUNLN3NWQnEzUkd4U205bUFYOUFhM3FYcndSOG9R?= =?utf-8?B?REVqTlpqS0FkWFVGS2Z2MmlRUitYamFhZHh1ZlRha0xVUTZkaU5SRUtpOWRB?= =?utf-8?B?WXNGY3ppaE92WEtyNndXVzVOK2tLTXIyU2JFNmYxd0VLc1hmMkJQK0NjNmRN?= =?utf-8?B?NGw3ck5OOUNmQ1VJaW1kZVlaZlh5TkQrU2Rhb2xta2JkeTBTN0ZqQy9nc0gv?= =?utf-8?B?ZW5veDlNQ2pML2EwTHBkRDJZNk5aa2ZMdDNBdlZINEkwS3BxclFrMmk3a01o?= =?utf-8?B?aDhlYUZRWld1MWRldzBiYlZEQUptTkNEdU5jWGtLdzhVenVBQjZsQmNZRVE2?= =?utf-8?B?MjQ3cE9kY0g5MDNhY29tdElNYkEzbEVkMm5VM3p4ZGcxWGJCektNZ05aZ0pM?= =?utf-8?B?NjBjcXkyY3o2ZnlNQjRqL3gycHhaQTdWc080NXk3eFBRSVkzbGVtMTVjT2dn?= =?utf-8?B?OEJKR2FzY1J2YXg1TURUa1MzbkxHSDgvY3hnTzVXWi9xZkJqc1h1YkhXbUdu?= =?utf-8?B?cS94cG9uUHQ0TmZFRXMyTzJlYVJuVlE1ajlZU2hjbXdKOVA2S2ZGRWtIUThN?= =?utf-8?B?UVlRM01UMlF3RlBSUm9HZ0FzNzJ2cW5MQ1JyN2dqNVh2TFpQZUlzeUxzUzla?= =?utf-8?B?TGFXSGJkOEwxTmVMZzhDbWRNbytlYVRuQW91MnFzREprQ0lJaFVEYzNXZ3VC?= =?utf-8?B?UEk3WDJqVVdlQWdlaWEvRDlmdE5Gd0pDMjBsTHFNWDlZaDkrblFSMnVGaEN6?= =?utf-8?B?OUhpUURoRXlQVkdmbVVRSDJxUjd2VFhmTUQ1aXZtakJ0aHZLdEI4c3J2RkZw?= =?utf-8?B?Z0RHNUYwUDAvSm9TL28wTnVSNmNQMlh6WXpMTFdpNlpyQ1BScHVxeENhc1VD?= =?utf-8?B?WTBVVkREUlZDWE4xclpRTklhS2pPclNqWlFNMEMrcGZhRnZuZzltWkttOTlM?= =?utf-8?B?QmdNWGhRaXZ3aWorOFIzSmR0UHRERDhDZ3lMV2hWVy9KZGc3ZG9UVjBsNUhE?= =?utf-8?B?aTFtQ2ZBWFY2QTRBM1p0RE16QTBjZmVhcVo4a2lYWWpFQk5GNzJhZUNTVWM3?= =?utf-8?B?WmQvdU5ZcDJtdWcrblQ1TVdZby9SWkowUHZwMjNhK1hhM0VMVFJVNzRvRzc0?= =?utf-8?B?WUduQzdHM3paV3dyZVRud2FRMEdwR2NEZ2luTEZhYWNHYzBXMnRGdWhJMmJ0?= =?utf-8?B?ZFFob3NtY2NCb2M5SnNGM1RTQ0VCaTVsVnpPMVlXS0wwcGcrMUJsdz09?= X-Exchange-RoutingPolicyChecked: bnYfE5eE9GZHnMy49BpICIq5z46IoE/+p1gzSZte3Aif1WEXoal1O4lXhwlInxW538mss/CWArPOnF1mvZdxBykij+wnip/RGjN1XVGu1cCd+V2OgX/0G8YVEUbEA2H8HoIQTrldVOuz62I4Rmm9nM/Zvm+16JayGAi6bGCjmKyL1MOJP2IRBq0JcAucxEq9DxmsHdLPdwDa8x3/QUsSFrk3D2ft74EiT4EFoH8uuz5+K4zOjhvAsbbhwnjr1s2SqHWUW2ZDaHb2vUhk0Ng9t/GyMh7JmUPsogTD+TDRIPcSZMeBdll5hqr+moZM7nmPHbl/XKOcjcp0GjzPPSxk0g== X-MS-Exchange-CrossTenant-Network-Message-Id: 293ad04b-2f07-4a5b-8d21-08deed78128f X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2026 13:48:30.0071 (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: yxj7cGLMoWz6ZGEkiDJH5fyZ4fkeASPSSXFFddQsyDG+91tsgNy3yizNWwWJj7oiep8/Bf/mB+hBEfThHbSBkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5260 X-OriginatorOrg: intel.com On 7/29/2026 5:19 PM, Luo Gengkun wrote: >>> However, is there a possibility that the current task_cache_work() >>> execution >>> hasn't finished yet when the next scan window arrives? For instance, >>> if the >>> current task work is heavily delayed or preempted by unexpected >>> interrupt, >>> jiffies could advance past next_scan before the loop completes. >>> If we move the `work->next = work;` to the very end of >>> task_cache_work(), >>> would that resolve this issue? By doing so, the existing `work->next >>> == work` >>> check in task_tick_cache() should fail and no new task work will be >>> submitted. >>> >>> Please let me know if I'm missing something. >>> >> >> There are two layers of protection: first a cheap timeout gate >> (time_before) >> that skips scanning until the next period, and then a try_cmpxchg that >> atomically >> picks a single winner among the threads that pass the timeout — this >> actually >> guarantees only one scanner per mm at a time, no? > > What I am worried about is the following scenario: > > Thread A (CPU 0)                             Thread B (CPU 1) > ================                             ================ > task_cache_work() >   | >   +-> try_cmpxchg() == true >   |   (Sets next_scan = now + 10) >   | >   +-> Enters Scanning Loop (jiffies = 100) >   |   [ Delayed / Preempted ] >   |   jiffies advances 100 -> 115. >   |   Thread A STILL in the loop! >   |                                          task_cache_work() (jiffies > = 115) > >   |                                            | >   |                                            +-> next_scan == 110 > (pass timeout check) > >   |                                            | >   |                                            +-> try_cmpxchg() == true > >   |                                            |   (Sets next_scan = > 115 + 10) >   |                                            | > > In other words, concurrent execution of task_cache_work() from two > adjacent periods can > occur under extreme conditions; Nice, this sequence is very clear, thanks. > do we need to take this scenario into > consideration? > > Perhaps we need an explicit state flag (e.g., using test_and_set_bit) to > ensure > that the previous task_cache_work() execution has fully completed before > allowing > a new thread to proceed, regardless of whether the next scan window has > arrived. > What do you think? > The scan iterates over a lock-free snapshot of visited_cpus, so even if account_mm_sched() concurrently adds more bits, missing them is acceptable. The same goes for concurrent shrinking by task_cache_work(). That is to say, in this rare case, a "duplicated" cpumask_clear() in fraction_mm_sched() might be tolerated IMO. How about adjusting the comment from /* only 1 thread is allowed to scan */ to /* elect a single scanner per epoch */ in your next version? thanks, Chenyu