From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from YT6PR01CU002.outbound.protection.outlook.com (mail-canadacentralazon11022114.outbound.protection.outlook.com [40.107.193.114]) (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 E9DB930E0C6 for ; Mon, 1 Dec 2025 14:48:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.193.114 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764600485; cv=fail; b=DAxCP7SazPKLz3RzGkGvb8Qg5jGNuaHov/GifwaR/rMUn8FA6SaDzShjEWg5+NumGOi17D1oOlHvCGSVYebcAcg0u66n+rMSFc/+gR2uSsFTgGZtPblKgNP4Pi8oeJapiUxiiqzSV+LMZAFMZHy604DQq6muSR3ijv8IwY2BmQM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764600485; c=relaxed/simple; bh=SjCf2QIR9sPCw1+hT3FfiyM6Weh+d8eRopk2atObD8o=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=Jnx+oZsFdhR4cN3Eo4KSnzDF8pH6udQ9p57zv5cnsRi9xqKLUHWrN121byP0P8XUalYykxTtO7xPU145lt4g5Wz62YoseyUrWSh/Es1xF29nBRQWVo3vjQfoVZCqWpxzt8uTrv/IxgCr4f3Y1OywolOpsbyUh6z8jLIKTl5uZaU= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=B+Tszxny; arc=fail smtp.client-ip=40.107.193.114 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="B+Tszxny" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ChEywuxJsJp7AQfz8AhZG4JXtE/aksDYTejE8UF3oxnLGEf/vK+YNn4oztLFFCstQohOOA/f2P4VkMDjCQmmi88hqsV8WW45cAf/oMktORbwMBxOGRtlII47JsiR9OoW6MxWQWOY6u7a86D0j2bQCMa/+lBjODueBVeeeZitzbhYM6GINFBMMhD8o6/9ZLbJMFxRrJkGlRCzCQdhzNts+4wUyRGRV2iYXRtcKMGH+T/G4TZKokR2cOfbGlxpgShwtVtHqvDGRilCvWs39dJRuidPVI22KKBwFPNmc7bvX0YxNRjrIEpO2HuswCOHbjxBW1n/mf3r3yJpkUtHTjsbig== 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=hlBkkpKg0qZqPMipUAWmpaH0vFsy4NUE/aWCrqMna1w=; b=SXHXmdCFH2wQc8evBPcbQ3m254TPPrcclcQteezv9SqKVj7ev0BzjDYGDiBMoyXiTD3vp0Pu31QX/crROhraK0cH1605mv2pzywhkrHfQUojOE1dzmVGkLHm1F3p7VT+pz6Ak/TD76aEfNGRlLhrgW4IZuGXgKnkeCCg2xTwfvSOmfcoIvy/picdreUKdTWvZX9hJHYo1bdF+Dkr01QPR/1/Fr2Y7qypCk2uPN6s2ArcSTlJW5Oc13kTJhPlEOCruafVy4ods1RSDb+Z6LKK9tS+SqvZdj/l5mIMhoWCTQj5CsZW0pXuK5I+bg9y5SPTGrnGr9g39x6gUkaEpx6cuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hlBkkpKg0qZqPMipUAWmpaH0vFsy4NUE/aWCrqMna1w=; b=B+Tszxny2HMygiSPqKAW+LfBQAXgd2QUOxONZx27m9Zg9Gkp+rFNI8pAAiGn7tkatN5xTSyeQT8BnAvsFJ/uhB0tHFtAOzC42dP6aPiJSU9d6yMy2xitn3ODJFzgTdRYi4n6hkSIoIgx/sD1+eIT7uls1EUZjTdirvEte6ruuEtkpsVxfqB4mCVLLHabWFbtexH2mMyvTIA5dGdlLDsuwCrmUKcyODKb7zqAd4jNAi9wORFwsYHNEHm71aiKtdzIn41axSo9hajpGu4eCm+MR+VvsaEXRQrLR71U54TuMgjurkTUa7RwLrTgDWR5AB7C6bQ9WXhN5diHd7BrDuI66w== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) by YT1PPF377CB8326.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b08::525) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9366.17; Mon, 1 Dec 2025 14:47:59 +0000 Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::50f1:2e3f:a5dd:5b4]) by YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::50f1:2e3f:a5dd:5b4%2]) with mapi id 15.20.9366.012; Mon, 1 Dec 2025 14:47:58 +0000 Message-ID: <355143c9-78c7-4da1-9033-5ae6fa50efad@efficios.com> Date: Mon, 1 Dec 2025 09:47:57 -0500 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/4] Optimize rss_stat initialization/teardown for single-threaded tasks To: Mateusz Guzik , Harry Yoo Cc: Jan Kara , Gabriel Krisman Bertazi , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt , Michal Hocko , Dennis Zhou , Tejun Heo , Christoph Lameter , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Thomas Gleixner References: <20251127233635.4170047-1-krisman@suse.de> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: YQBPR0101CA0183.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:f::26) To YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) 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: YT2PR01MB9175:EE_|YT1PPF377CB8326:EE_ X-MS-Office365-Filtering-Correlation-Id: 3a5e1ef7-8698-4d46-edf1-08de30e89ebc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Wjk3MzdKb1JLNzFIQ0VBaFBDMHVZRmNoQ1Y0U0tQdVhGanNKVUMzNzFuVDlG?= =?utf-8?B?QmhYcnRHZ0hzK0VIczZ4N3kxdDZmNmRPV29yWjNUZmJwWjl1SFRhcGVZUEx1?= =?utf-8?B?UCtxOEtlTlc3Ykl4YmdLYWFOaFdYQXF2OXk0TUhIa3RhdlU0c2NabTcySzQw?= =?utf-8?B?eDk1WTR4RGEvaThWdjNVM3pJRE0wbjRRU2tYb3JVd0ovK2VjSExMalVxcGZV?= =?utf-8?B?eWl4V2ptSXZyd0tVYXRhaXozUkpaMmlJVFFncHZkMUNXV1RnTHB4d0J3bGFu?= =?utf-8?B?OGZuMkEzZ1A0eC9mTHM0Yy9pSXFtL0NlZDhSeUEvYk9OQXRwVml5bCtXYjFQ?= =?utf-8?B?eHd4VUxHWkc0MXNNMmhyVUJRRXA3OStab0NnaVdOTU4zaHBNdGR3c21aRzF0?= =?utf-8?B?bnFxajhRSTdmMUczb0ZQQmFLR2tQNHFlT3p4SEpuWDFBQ2N3OVRFSVBwZ1dD?= =?utf-8?B?aXJUY1B4UnYwM1FKczRZMW0ySnJ5R0g2MVVIaFZiMkwxMzk2MEJSaFVaZTJC?= =?utf-8?B?a0M0Q0Y5UUFGOFgxUU90U2s5b1V5TnZmcHk4UHM4MkwrVUJEUkFGYnRDQ0Ja?= =?utf-8?B?bnJob3FHY0ZQT0pValJkdUV4bERCVzZUN1lNL2lOa0lxcFB3eGFFbGQvaW9S?= =?utf-8?B?Z25PWVpTTCtyTUFVZFQ1MWtrWGo4U1lnQmJIbzN3amQ2cGFhclpuNkV0S1Y4?= =?utf-8?B?bENNV2c3VDBqNzAvMGtORFVzY2pVTmowS05oUWlPdFpNTFEyOFpZOG5Sdlkv?= =?utf-8?B?SmlKUzZvZlpJT1BNa0ZjY0RHTE5uNHlZOXJ5U3gvZSt5TkhBMUF2ZW4yaGhL?= =?utf-8?B?Wkp0OHJHR0pYS2NVdzg5cVJXaXFyb2xMeXFDVU5jZ0cvRUgxMm40dnpPYk5P?= =?utf-8?B?WHlGQ1FYQkhqMnhTS0lkT21xaCtDZ0JMUGppTTJ6LzJiQ2JoOSs3QmRLVUdz?= =?utf-8?B?UGlVbW9HNEd1VUtyeHVwakUvOXZZOERVc1N1bzZMT3h5KysraVZ3blJtbFB3?= =?utf-8?B?RnBsUURhNm4zeFhhS1B0cE5ZODIwRzhwcjcwSXV3Z0NEQ05VbGg3eUt2T2Rm?= =?utf-8?B?RXpRenpla2tTS01NVUc0T0ZEV0xzQkdnakJlYVZOZDBqVzdFTjVQejlOcVhn?= =?utf-8?B?eEw4U1J2em9ZU2NvaWtTRlR2ckJ6UUtWS2trcmRTRGhURzZpOG0rZStaVlNU?= =?utf-8?B?Y3h2b3dxVEVDT0d1SUtjSnV2ellFc2t4M2RvY1IvTGxFUDVpUW1HRmpqN0JF?= =?utf-8?B?S1ptSE1OS1FDZW9QZVRwVWhPUDRwMktOVnlxK1RBc280MlBueVNmaUt6bTVK?= =?utf-8?B?aE1kTjA1Qk44OFlrSFNCZDZoTFZsejJzbGIvRzluOTFLK0FiZHNDN0UrOERs?= =?utf-8?B?YUMraUpacWFYc3NVZzFZSkUvZlZYbUxDNSt6M1hCdEhCNWpkM3ZDOWp0ZGNz?= =?utf-8?B?V1ExeXJ1U2VyNmVBSExVd2RoZFhFS3QrZEtKeFFSZnAwb2E4TE5tQVNpSWFW?= =?utf-8?B?ZDhaYnJIbENwdml1bm9HejRNWk5kdlRYbmtyaEs4LzlIZDZYbTVzSEdIQ0VP?= =?utf-8?B?cDVTU2I5emhzVTdIMGxHdnhkVUxhSSthaGI1eU5BYXpmc2wwbUVUZ0JRMGd1?= =?utf-8?B?WVNqckp0U2tVVUJocU5TOGNCU2ZwVXhWQ0R0YlpxMXU0ckljU0FxczFtd2ti?= =?utf-8?B?TC95VjNwUjh4aVI3OHhDNURJTHYxUlNUS2h1bnFxY0crRlpPaXpNSk1BNHhQ?= =?utf-8?B?SmJHQWw2THk0Y2o4NEdPdVV4WFJoU3B5UFllRXJaUlVIUU5jalJMc1NHNm9P?= =?utf-8?B?aG16V0gvNEVPYlIvSGJwZTdGWlVSQyswTTFaQTFSSXU0R3p6VDJMbmErVFpE?= =?utf-8?B?WkxiVytFNzQwN3JORDJjWUVrM2NUQTlnSlhVTndhekIzZ1E9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eXppWitUMy9YQ0k2K3orSWxxNDd2dk0vQkJFU2RvczNQb0NkSkZVVTFZNENY?= =?utf-8?B?bEFYQStnc2N6MEFRdkVnN0pCcktrWU45bEVCV2hoNWJESGZaa2hsQ214YnhC?= =?utf-8?B?U2hrNy9WNEhvT3NoQy93SHl6MEZOaklXMHI0ZlhJU3hKbHI4eHNVTHNYYUVX?= =?utf-8?B?M3lpMjhZZTI3aTkrZmJDZzBEalZZMUdKZG5IWFBHT0l2c3JKam1HazFXRHJO?= =?utf-8?B?eWdFbmFJLzQ3MThrcnV2VjVGS2doMFBPV2wrcUhKcUZSZmQ2SXBYZ0FSUVI2?= =?utf-8?B?d2lPVFA3YTA1NGlQdUd2cVhvS1pTbTlDMlRSeU9EckNrdlhFdWc1VVNXVkda?= =?utf-8?B?YnFVZktydTE0T2ZMN3phZkcwY0JBNXZUVXQ4YVJybmkzL0F0b2VxT2gvOUM4?= =?utf-8?B?WjYydnp4QktaZW1FYjRQeHJCd05PdGN1ZlJWa3pxZzJIeHQrKzFCMk5KSzZv?= =?utf-8?B?V1MzQkVIVHB4dmNPVFhpVjFzM2JtbThGdkF2dkZyN202Y2pwU1JKZ2k5eWRn?= =?utf-8?B?RWk1TkNUZnR4NkVuVUZ6OXAwR3VFYkNvTUdsb2Y0U0hhM0lQbFkrNk9ud3pH?= =?utf-8?B?TnlDNEtYNlFnVDkvelRqOFlIbXFXbDY3eXB1cU1nVFl6ZUhEU1YvNEZEZkR6?= =?utf-8?B?ajM1K3ZlQTBBQnhUN2J0UnlaVDRUUGpZL0RqRyt2bUlDaTFTekZWSXpBaGNQ?= =?utf-8?B?bms5Nlo5M21FOUNTQlNJc0g5dnBlSEJWcmQ0TGo5SUhqM1ZZdlNveUtoY1VH?= =?utf-8?B?VmVxQTllZVhaVStRWHdDMUFtWEsveDlMbklHL2tjaDVaVndZMU9oQzQvZFNr?= =?utf-8?B?V2lwOFdESjJUM050R1YwUUF1Slp3Vll2R3RaazB3VmxTUFZTcHdETmpaRHlm?= =?utf-8?B?YmFzMWdyQUQ5WmEvSmxFenlRbGdFV3BZYWNFNU10dGNQTVpSQ1dhalN2YmhC?= =?utf-8?B?YW5QTndXRmYrbm5JOXlKMEk4VGpHMVM1SWdweWlNQ2V6d0d3N0dKUkxnUUJ4?= =?utf-8?B?QU5rb1BsYUNpTnpEUG13NThmS3hiODA2QytPV3F6cXNsaVFVcW9hL2RLRGRN?= =?utf-8?B?LzJkSDJQUlRIUm01V3M2eFlWR2lycVVrRkgzeVN4YkVHQ2lwdkx6Rlk5K2NT?= =?utf-8?B?TjlJUDhrTHgwUE91RDFSNlZZT0NBVUd2OVc0TkJBYVc1SmtzZ1F5cGpxV2R5?= =?utf-8?B?TENkOEYrVXdrUU10WGdvTGNWRVBFRXFNZWZRTWo0MDI3OW1NTVdyZW9wa0RO?= =?utf-8?B?bHJzMnNSVit0Tm9pL09Yd0ZRVG1nKzI0Z01FTkdHdEFMZjJFcjlzWjB0VnFm?= =?utf-8?B?eWVkVXlST3gxRnBiQm5YclVDcTdvNysweDFPREFQUkVOT01QS0JRd0VMekVM?= =?utf-8?B?UjFZaEo4TzMzN080QlFPVlpVeE9HN2xZeU9RRjZ1aUNDYzIxNllhVVFTMHUy?= =?utf-8?B?bU9leVNHa3dYUis3ejhlSk5nMzlLTk0xbXZGc2pjbjkvbURmUUo1SUVGTWpL?= =?utf-8?B?cVF3cGdyVm5LTGNUVU9BZEkweERlUUNPdmhqZGczdXlQRWxRTWt5QWhBRUw4?= =?utf-8?B?emJyT29OVGFqTVFSdTBjMmlQVkhKd0tqOXdRYjNiRHRoUWFEZDAxTEtvcHhm?= =?utf-8?B?Ui9uTCtZa3VCSFpNK1lWamhyNGVxNU84QmpBVEFmcGJSRHI5VnZEdFVPZ2pK?= =?utf-8?B?dGlvZjMwRjAwV0wrTFN2SXpVR3ZPcGF6WWRnN2I0VjErUDlNd1IwOE9QUE5I?= =?utf-8?B?WmtrbzlDZERzb3djcXhtWlRodVZDcUJJQURGdyszWWtjdExkc1FvbEFFNE9E?= =?utf-8?B?bnN2N3pIQnlXdXpHSkZmODZZakdRMHJjYnVNbUtTNVBFd1JEenhyeGt2dldS?= =?utf-8?B?bUI1MWtINE9reGJiem56Y0xlM3RYQndKWk56R3FQY2NlTnZUNS9HNkNvNmxM?= =?utf-8?B?N2tIU0FnRUVoZ0pzZ0p1blhyYVlJMlRUQzNJZ0YvQjFOOG1DK243MExjVkR0?= =?utf-8?B?OFJZMlRhSG5QenI3cEYxUDNJb1dGZDFMTWx0Rk02dTJlTGRwWmRwSTVrOHhH?= =?utf-8?B?UXVna2hueVQ3VVhKOFIyQW9QbUpIK2I3Z0t4SEFHVWpDQ29TaCtFK0UzZ3dw?= =?utf-8?B?djQzclJaUXlseFdJM0dITFh1ZDlFbFUxRWtIS3V3RUh1ZmZOc3NRdnBpQVh4?= =?utf-8?Q?1+8lHgZgwU5cSZGnlm1g2R4=3D?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a5e1ef7-8698-4d46-edf1-08de30e89ebc X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2025 14:47:58.7894 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: g6q2tVoWCaOUaPk4PQYQRQsecWKfDae7rFGKgC1t8HOTdMWLi4armQQppgeZaGPeBRDP9A0Uc/afP/obg3iAXSYrjYPERh4CMYEpFXRWXd0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PPF377CB8326 On 2025-12-01 06:31, Mateusz Guzik wrote: > On Mon, Dec 1, 2025 at 11:39 AM Harry Yoo wrote: >> Apologies for not reposting it for a while. I have limited capacity to push >> this forward right now, but FYI... I just pushed slab-destructor-rfc-v2r2-wip >> branch after rebasing it onto the latest slab/for-next. >> >> https://gitlab.com/hyeyoo/linux/-/commits/slab-destructor-rfc-v2r2-wip?ref_type=heads >> > > nice, thanks. This takes care of majority of the needful(tm). > > To reiterate, should something like this land, it is going to address > the multicore scalability concern for single-threaded processes better > than the patchset by Gabriel thanks to also taking care of cid. Bonus > points for handling creation and teardown of multi-threaded processes. > > However, this is still going to suffer from doing a full cpu walk on > process exit. As I described earlier the current handling can be > massively depessimized by reimplementing this to take care of all 4 > counters in each iteration, instead of walking everything 4 times. > This is still going to be slower than not doing the walk at all, but > it may be fast enough that Gabriel's patchset is no longer > justifiable. > > But then the test box is "only" 256 hw threads, what about bigger boxes? > > Given my previous note about increased use of multithreading in > userspace, the more concerned you happen to be about such a walk, the > more you want an actual solution which takes care of multithreaded > processes. > > Additionally one has to assume per-cpu memory will be useful for other > facilities down the line, making such a walk into an even bigger > problem. > > Thus ultimately *some* tracking of whether given mm was ever active on > a given cpu is needed, preferably cheaply implemented at least for the > context switch code. Per what I described in another e-mail, one way > to do it would be to coalesce it with tlb handling by changing how the > bitmap tracking is handled -- having 2 adjacent bits denote cpu usage > + tlb separately. For the common case this should be almost the code > to set the two. Iteration for tlb shootdowns would be less efficient > but that's probably tolerable. Maybe there is a better way, I did not > put much thought into it. I just claim sooner or later this will need > to get solved. At the same time would be a bummer to add stopgaps > without even trying. > > With the cpu tracking problem solved, check_mm would visit few cpus in > the benchmark (probably just 1) and it would be faster single-threaded > than the proposed patch *and* would retain that for processes which > went multithreaded. Looking at this problem, it appears to be a good fit for rseq mm_cid (per-mm concurrency ids). Let me explain. I originally implemented the rseq mm_cid for userspace. It keeps track of max_mm_cid = min(nr_threads, nr_allowed_cpus) for each mm, and lets the scheduler select a current mm_cid value within the range [0 .. max_mm_cid - 1]. With Thomas Gleixner's rewrite (currently in tip), we even have hooks in thread clone/exit where we know when max_mm_cid is increased/decreased for a mm. So we could keep track of the maximum value of max_mm_cid over the lifetime of a mm. So using mm_cid for per-mm rss counter would involve: - Still allocating memory per-cpu on mm allocation (nr_cpu_ids), but without zeroing all that memory (we eliminate a possible cpus walk on allocation). - Initialize CPU counters on thread clone when max_mm_cid is increased. Keep track of the max value of max_mm_cid over mm lifetime. - Rather than using the per-cpu accessors to access the counters, we would have to load the per-task mm_cid field to get the counter index. This would have a slight added overhead on the fast path, because we would change a segment-selector prefix operation for an access that depends on a load of the task struct current mm_cid index. - Iteration on all possible cpus at process exit is replaced by an iteration on mm maximum max_mm_cid, which will be bound by the maximum value of min(nr_threads, nr_allowed_cpus) over the mm lifetime. This iteration should be done with the new mm_cid mutex held across thread clone/exit. One more downside to consider is loss of NUMA locality, because the index used to access the per-cpu memory would not take into account the hardware topology. The index to topology should stay stable for a given mm, but if we mix the memory allocation of per-cpu data across different mm, then the NUMA locality would be degraded. Ideally we'd have a per-cpu allocator with per-mm arenas for mm_cid indexing if we care about NUMA locality. So let's say you have a 256-core machine, where cpu numbers can go from 0 to 255, with a 4-thread process, mm_cid will be limited to the range [0..3]. Likewise if there are tons of threads in a process limited to a few cores (e.g. pinned on cores from 10 to 19), which will limit the range to [0..9]. This approach solves the runtime overhead issue of zeroing per-cpu memory for all scenarios: * single-threaded: index = 0 * nr_threads < nr_cpu_ids * nr_threads < nr_allowed_cpus: index = [0 .. nr_threads - 1] * nr_threads >= nr_allowed_cpus: index = [0 .. nr_allowed_cpus - 1] * nr_threads >= nr_cpus_ids: index = [0 .. nr_cpu_ids - 1] Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com