From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 C88AF3859EE for ; Tue, 18 Aug 2026 14:42:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.21 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787064131; cv=fail; b=C7hne5mA3UozaSOJpftwfIhwD3V/o6R69bGII7P5hk/hDzx2Eh/08yWijeh9K0iW96N8zI9kOjYoB/TCpXJ2Y2c4ixWeLw4jZ7wr91n4oOAD8EV7n1Wf5rfKKX++br6Dqr77ha420Hvt4xbwF2zHgLakTxMgbDic52u3Jb/xqzk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787064131; c=relaxed/simple; bh=bsxFELleSRdbRVrQZeLFCXeLEwyi1yHWMNazCOYr9mQ=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=FWldQHcWTeDcPy/5E3UpLDaaHQwAXSbQwL/PRLk+wOTX/gUcnVmnq/tfsl7CRSKxRabMMR/xvL+K5wcWTlPqg7EgmC373WEV/+llZ6tv8xR1IK8y5Bgo4WW9/IHLW0Gsqt9qPZhzLXV5pBy5+7IxzNWu9/kk3jCrUrg/HjJ9ttM= 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=UP78Rd0z; arc=fail smtp.client-ip=198.175.65.21 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="UP78Rd0z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1787064129; x=1818600129; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=bsxFELleSRdbRVrQZeLFCXeLEwyi1yHWMNazCOYr9mQ=; b=UP78Rd0z1g0gd4Po/dMmledvI4ggVGTfkLa3eurrqwE5X2ZfL1n16ZMO dRlOCYXm4eV5G19igl0NuWgWbLcRYoWZHaWOxU4VNoeQPzo1sUw/493eI HT8t93Qs1rluNxEWCs2XtH2ukkAYXV+a539INLbMAiQImCcTwP0ClH6Yf hLqbWmnu3IiNoyLgdiPraXqp4j7PniMMRbC7q3/Y0fCDypMxCXIHVZDZo SiGmXSI4W34UPkdgm7dSt6hVaeqxXi4iCh1ogNG2vqPkM+zDsnhvPSton CKeuEkSGP94geEDHGPUhrJJRl8f3H0XwZPL/KLJqSsyT5IPEjDZz6LX4d g==; X-CSE-ConnectionGUID: cOCCSqYwTN6ZPrcINjQT8g== X-CSE-MsgGUID: 5Czu/yG2SDO9AvZIFOuc9Q== X-IronPort-AV: E=McAfee;i="6800,10657,11878"; a="87412161" X-IronPort-AV: E=Sophos;i="6.25,230,1779174000"; d="scan'208";a="87412161" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2026 07:42:07 -0700 X-CSE-ConnectionGUID: hYPty2EMQLqleaacxTX4GA== X-CSE-MsgGUID: hLiOwQUjQoOTbtptbtB9kw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,230,1779174000"; d="scan'208";a="290043387" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by fmviesa001.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2026 07:42:06 -0700 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by fmsmsx903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug 2026 07:42:06 -0700 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) 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; Tue, 18 Aug 2026 07:42:06 -0700 Received: from CY7PR03CU001.outbound.protection.outlook.com (40.93.198.54) by edgegateway.intel.com (192.55.55.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug 2026 07:42:06 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nKFarMATb6qpFIVhhVqtfTUCzGpAenNy0KF+HE8EjSU8H0L6cdfAhltDMAXhZCv9ID5lOdmxKHvffvKEVMDWlcWVTHmHtM1HcPwezY5su6pP7C+hCxMpfHbeRvRIuzh8TNQ4wHBI3OKzUHZAxxvh3ieW0sxmvab8JPU7Rh+z6BsaprcqgTNAFyx4vsxX8gGwM0wg1fonxJeCzCPZLlauoJqswuJI1JkT1PhySlRu/ruMvyzi0S/N21pAsVF/m8GqZPYbTcMfioTwHP7LSqecx0jIo8w6ZPgudXmyD6SPxHI37r0EPREWiTnhYacwP5Mtb0gsP0Y6vsDX+9UeJlndew== 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=q3hqBQD2R7/7ohClsl68sNXdzafoNEs/2g7GBsTx7q8=; b=lc2SND84YGMJi7TdX7Jmy4OjIBJbShMoqM1pHtI18+mfXRfWwBxGK7uuu2/+qcsoymZ/WBbYsOfhJWDlV1P4pqgh4LUZlAEhNK5BLGsk7BasBKoa4mWF0lPSPVku+LzLQrm1nEIEup4M8aANynkAfOFZOlXqwjV7VDdfp0B79ZOlUkfkP4rPISlkI4pjawO4Qqjt4F35yP43hgiIhflKQu07gLwRIBrPmnDxRUbLjf9c5aVJzpSed5gXxA/S/MYHcnxh0HkfrCzWrNEyj3OA5eCtbMxQTALDvjIdx+Zy66Je+7paAQwwa2+Icu3QV86+VosL/O0YmZKUtiyAy41/NQ== 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 IA0PR11MB8378.namprd11.prod.outlook.com (2603:10b6:208:48e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug 2026 14:42:03 +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.0339.007; Tue, 18 Aug 2026 14:42:02 +0000 Message-ID: Date: Tue, 18 Aug 2026 22:41:51 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus To: Luo Gengkun CC: , , , , , , , , , , , , "chen.yu@linux.dev" , Jianyong Wu References: <20260731024417.1106503-1-luogengkun2@huawei.com> <20260731024417.1106503-2-luogengkun2@huawei.com> <9fae7258-5f33-4ddc-8d21-599db3c0d091@intel.com> <228dff06-1cf1-413e-a1db-0aefda384479@huawei.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <228dff06-1cf1-413e-a1db-0aefda384479@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SEWP216CA0018.KORP216.PROD.OUTLOOK.COM (2603:1096:101:2b6::13) 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_|IA0PR11MB8378:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f237b78-4b9b-49e2-d993-08defd36ddd9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|7416014|376014|366016|10067099003|4143699003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: kyhq6A49JY6Bpw39PyGrKdv9pc17OvsoC1ubeTgpXU+MLqaiea5MB+ndwCR867EAXCoEwK0K5xFcxOmdbe4eTln8joj7a8yp/v3UCR0n1kfCOQ/uIfYDbWXWUKXU2qofzTtyBTJnvNakNhcGYQrZ9YgykQi+79icWKf1k5BqGfnxJzpvcArCunaFCf5s6oLphsRVuM9ZJ5tz2sZXHyxB9q8iUQYVWWJ1O+KhY9FbojOQr3X8yaCatdik3IRoaxC6+0NIeyuX0YEyZ3Ybgn8KaqqoNCsbt0PhdetjJmfRfJ4hhQAJHyE7B045xwsfzyNRQK84+Mqy82UYD+EULWu9IJKnHc8fXyLkNk6zrFWbXRwYUyMXJVpLuUITjQJiYDtEWBsl3FXxM9JxNZFZ1PNPA9+gQpIYj41Tt+3tZDWME9jvkbGwvCNUv4pSFbJiPxXzEUbYJQsUsR846NsnJuAQ2FGiSBSBUpv5F4WaXMQmWEqkc4dnXqZ/xKEOY78vFJU5gpvR9isu9W6qXbrSzOiTloMLe20ny+cBfYjaHyYwIRteZmC7Rc3srBQL/I5DDtSM8KCpPbhUlBlQI81FQXxHbqSpXUVql6GMzw9FkvrUfnxY26ifrLzbhzFLLv6QwFnAoBduJYXQ+gwqpIXGByxAem+RW8AJwEg0pVWTf3TN5HU= 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)(23010399003)(7416014)(376014)(366016)(10067099003)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cjZUNVhtWXd4STQ1Y1FCUkMxVUhwdlVnZ3BhS1JhSXUzSndCTmRhaEhGZ0l3?= =?utf-8?B?T1V4VFQ2ZVpRa2tJZCtyRmNKd2tvKzBJTTFMd2pBVURxMUFOMVkveERLd1ll?= =?utf-8?B?UjhwS1UvTWtEdWppSUtQcHR5V2RORmo4c015Q3FqcnlhbThKZ2lHVHVtTU1O?= =?utf-8?B?bE42dGhadnkwK3dNWThYWEFKTlBpMllwN2I1aU8zaXFiOXpISjZEb29pbWVV?= =?utf-8?B?QmdOcDBKWmFTaktOY21uanYrQTZWL3BZdEU1VXh4UnY4MHhaMU1tQ2c5MlJ3?= =?utf-8?B?a2VqQVRsVGFMVHViVEhEQTNrSDE4b0s2Z1BERk4rUkZSUmFqUm9FckVUc25C?= =?utf-8?B?Ynlwb09xVGlpUTMzNXB4Q1k1VitVWFNZSHNXQnl3TzZYR3EzcXJxOFh6dmtZ?= =?utf-8?B?OWEzVVRKWGs0TTN4c3Z1aG5xK2prWFZkVi9aekpUVTBlTTVKMXk1SDVxbTJB?= =?utf-8?B?dnhoVVRoQlZLaU9BMFFnMkJsNFJrQXhnb2xpZFZXdEs3eU9LS3R0ZWJFUDJC?= =?utf-8?B?SEFWQVU2Z3l5VDlFNE5FeFllS0YremhYSzJpbGd1elpnUTM1eUR0dU1FUmJz?= =?utf-8?B?bk8reUhNNWREbHF5V0F6aWlaZ3YzaGFhVmFZS3h0QTQ1cDk2NkYrTzk2T0Er?= =?utf-8?B?TFlWekVBQ20zZURNWDlNbS9pVUlVdjNBb3FpVWdYRHFBVDRjM2hzQUhLajdp?= =?utf-8?B?cURDU2VoYmtEQjE3RFA1dEVteXJJMzlMWkdQRDlUZGttUk9Ba0ZFMkRLOWRx?= =?utf-8?B?bTZ4OHkzZ2E2bTR4SHNOUkVFVXYvQ1pIbEpMQUJlT3dqMXRQcm83QzRnQ0Yr?= =?utf-8?B?aGp2eTFSVjVHYUZGZ003dTcwTktKTmZxU1FMS05uQm5xTmdUeTE1cC9zYk5C?= =?utf-8?B?MVhuRHcxTjNoV2h6MUhUK0RCZU1aQ1Vxakw2SERPdk91amdTZjBGdHR5czFw?= =?utf-8?B?ZEl0VjRUMTkzREptL1hBUWVwcFRrSWNpbGdOaks4YUZGWjBkbDd1UGI0NkJP?= =?utf-8?B?emhKaFR6dXFOajRIdThEamY3MUp1UERsVEhhNzFUZmQ1dDZ4M1pTMDcwVUZD?= =?utf-8?B?SWpQbWhiaGF3a0lweHpKMWRIb1BSeWJRUndnRHhDeHg5TVh1TmtvWS8rWUNC?= =?utf-8?B?WUN4TWVYTnRNT2txRkxRUkRaMzdlU0tGZmVvaFB3clNYS05XbjF0VU9PMXVk?= =?utf-8?B?NGlVaXQ4UUN1dG4reHNWS3U2SUlyM2xlS3pSdy9zSWd6MDNRTTRaRXJva1ZS?= =?utf-8?B?YTRvNXJKVTFkakg0Y3FrOVRwOXpaSUVZY2ZwVlRnQ0VUaTJZdWo0M2x0MnlN?= =?utf-8?B?YlBDc25taERMR0Y3YkRzb3FseWF0S1B3TWowZVNzc1c3bDBmeHQyN1lnWEVs?= =?utf-8?B?YmNESjBIcVBTMGJqSithS2JZUzk3NEZEdXhmZVNOYlhtTGJ1TjQ4NHFnRERp?= =?utf-8?B?WlBjOUFGdWQyRXRXSFU0bmtUcDZpbE9Wbk9CdjBKNTFlQWxuZFd5eGFRbW04?= =?utf-8?B?akJ1Z2xucmJYaXVrK0NxM053Sk5qKzBlUjMxWVBwMUZZb0pCZ0kwZTFjQ2dX?= =?utf-8?B?d2FJNjI3eVJjNUs1MDcyanZJUTlLNStQS3lLSkZvVWt4ZUltYXhlK1RFQkpQ?= =?utf-8?B?Y1BRYmtsN0s0c3RXSkU3dXNoRER4TWNIT0JsdVNwbHNUQ0J2RU5LTnZVR3Vp?= =?utf-8?B?Q3FoZHFuUXEveEtyODZJMUFua3AvMmlwS21IRXdYRERNVGJsaWltL1N4K21L?= =?utf-8?B?ZzJaZlhrK3BXS2lTSGpVZ200SmhNdnFFd3AvVXp5NHBvaUZXbFNpRTdlMEpx?= =?utf-8?B?MGpYdG5UNkhyVEcwSVBPckwzRmE4Z0lrbmM2Zlk4akd6dGpLOGRXbjA3V1I1?= =?utf-8?B?amRnd25reU1WTUMwcnl5Wm5zWjJSVHVVK0gyTjJjWVlHVWNsSE9LM3YyanJh?= =?utf-8?B?TUdTcEVtT1pvUXYzUTZCWFZSVjhSSmhWekZXZXJQSUUwYks3U3FJcWNvUFRv?= =?utf-8?B?OEcyWVpXc2w0TnJ1b0VGc2pkOGFNSG1USDcvdzdYYjBaeUdjVU12aXphQjFQ?= =?utf-8?B?Y0ZCcDZsQkJPUTd2aXJWdVpDODhYSGxnbEUwWnR0RlhpQVhndFZ5cVpVditX?= =?utf-8?B?ZW1sODBhWEVSb2Z0Q0pVU2kxb1duYWVNZk1hN1RXRmZwd1JFaUxzUW1Xd2M1?= =?utf-8?B?NlpFZjJTbk1rK2U4dEwwTG1BOTlNcEFkTDFVQlRyNFpuU2dLTmNjTUhXK1hx?= =?utf-8?B?bWZSaWUyZW1ydklVZUVtUGJXZHhRRFVYWE1nTmhPb0dIWEp0clBBLzdxTCsz?= =?utf-8?B?MWNsVFFBRU5kVUp0SDJLbzJrOGdnSklJNk5jR2ZFWlFFenhnVUpOUT09?= X-Exchange-RoutingPolicyChecked: WWyjgeq5pw9T/sE/RpzQ7J5W027aS+Uk8iiOfuHpNgP9oCYtHaQ3E86K8ggNHacgbAG6rY06imRLXtoqkG8C7YFFWzVocXnl7Uj9ZyKhLWvGlSm1JB5HtbwZzgI0HCYxgrAz0Cjp69hPL65NWhCe+hT3yl0bpQWE/kyF2UzaS8dImQ3FS46XSTr5Xd7KrjsjtXM7HPmvYmAyKOxFN4ds8jbggmjeQ3ft9/W4Fy2d76YM1DmLqy4WkvYheFlHcHjSRGX5jNVMpLuHA7OM+pAxJnXM4g7sSA8X7LcCowP5mM/NGssaOd2K738r3W5xCh0KBgEaf+1C6Btxk1a4v70vdg== X-MS-Exchange-CrossTenant-Network-Message-Id: 0f237b78-4b9b-49e2-d993-08defd36ddd9 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 14:42:02.8031 (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: 0+ht+BrrF0G6ZboWMAOOx1fJwyTasSLbbt/g5snDkIv7MiJ/jkKVKV6u131/FhBqLfLIxaqwJLq7/NGneyXAKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB8378 X-OriginatorOrg: intel.com On 8/12/2026 5:03 PM, Luo Gengkun wrote: > > > On 2026/8/11 15:46, Chen, Yu C wrote: >> Hi Gengkun, >> On 8/11/2026 10:27 AM, Luo Gengkun wrote: >> >> I did a further study on this and have two minor questions: >> >>>> @@ -1711,6 +1722,9 @@ void account_mm_sched(struct rq *rq, struct >>>> task_struct *p, s64 delta_exec) >>>>           pcpu_sched->runtime += delta_exec; >>>>           rq->cpu_runtime += delta_exec; >>>>           epoch = rq->cpu_epoch; >>>> +        pcpu_sched->epoch_last_visit = epoch; >>>> +        if (!cpumask_test_cpu(cpu_of(rq), mm->sc_stat.visited_cpus)) >>>> +            cpumask_set_cpu(cpu_of(rq), mm->sc_stat.visited_cpus); >> >> visited_cpus bits are only cleared inside fraction_mm_sched(), which is >> reachable in task_cache_work() - but that loop is skipped when >> invalid_llc_nr() >> returns true for any single-threaded process. As a result, single- >> threaded >> processes keep setting bits in account_mm_sched() without using them. >> Maybe a gate would be useful: > From a technical perspective, adding a gate here is unnecessary. > > The overhead is virtually nonexistent, especially since it resides on a > path > already burdened by heavier operations like __update_mm_sched(). If we were > to care about performance and optimization, focusing on __update_mm_sched() > would be far more meaningful than adding checks here. > > What do you think? Makes sense. I was previously worried about the multiple accesses to the shared mm->variable, but since it's only a single thread with no race, it should be fine. >> >> if (get_nr_threads(p) > 1 && >>      !cpumask_test_cpu(cpu_of(rq), mm->sc_stat.visited_cpus)) >>      cpumask_set_cpu(cpu_of(rq), mm->sc_stat.visited_cpus); >> >> >> [ ... ] >> >>>> @@ -1866,7 +1835,18 @@ static void task_cache_work(struct >>>> callback_head *work) >>>>       scoped_guard (cpus_read_lock) { >>>>           guard(rcu)(); >>>> -        get_scan_cpumasks(cpus, p); >> >> I'm thinking of if this could bring cross-node bouncing. Is it doable >> to honor the result from NUMA preference: >>      get_scan_cpumasks(cpus, p); >>      cpumask_and(cpus, cpus, mm->sc_stat.visited_cpus); > > I looked closely at get_scan_cpumasks(). The CPU mask it returns is the > union of node(p->numa_preferred_nid), node(mm->sc_stat.cpu), and > node(task_cpu(p)). > Its purpose was only to mitigate sc_stat.cpu bouncing — it did not fully > eliminate it. Relying on visited_cpus alone follows the actual footprint > of where the threads really ran, making it even less prone to bouncing. > > Additionally, even if the numa node derived from visited_cpus disagrees > with a > given thread's numa_preferred_nid, get_pref_llc() still prevents that > thread from being migrated to that node, so it remains safe either way. > > Please let me know if I'm missing something. > I'm not against removing the node-aware-scan-first strategy, as long as it doesn't cause any bouncing regression. I also heard from Jianyong who is working on extending the CAS from a single-preferred LLC to multiple-preferred LLCs, that removing the NUMA-based scan would benefit that work. So, your change on this is fine with me. thanks, Chenyu