From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B592BC369D3 for ; Fri, 25 Apr 2025 19:03:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 060086B000C; Fri, 25 Apr 2025 15:03:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F02346B000D; Fri, 25 Apr 2025 15:03:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7C796B000E; Fri, 25 Apr 2025 15:03:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BAAB56B000C for ; Fri, 25 Apr 2025 15:03:52 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 36D2A1606D5 for ; Fri, 25 Apr 2025 19:03:54 +0000 (UTC) X-FDA: 83373490788.04.B77B998 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf22.hostedemail.com (Postfix) with ESMTP id 95DDEC000E for ; Fri, 25 Apr 2025 19:03:52 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=asHGJjoU; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of tj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=tj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745607832; a=rsa-sha256; cv=none; b=xeRa+6xRpew2qpSX/I6vADsNPdg5ytaIlV6zO2Td3BWYfZhYkXSPlkVLU+aPsfH+rA9Pxu xBPnd9Q+9naPfxJlus7ZO7H4AmZWaKkjJgrJln3ik8ADg9UnK7Ttw3U85cuO5KC8CBbe0y 9VfPEzOJGfR8Ae03i6DIp4TwkEBuZ90= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=asHGJjoU; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of tj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=tj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745607832; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4zjWSJM+Oo8Y6CGj5K+emwsF4c9nHACz2yGnczyqug0=; b=lQYMNapcK6a636kALfwwI+mqRMvqwI53KlRhVn8EQtgIvLRlc1WcqiK3aSMUfv+BUF6jkS t6YZJDDc9M8TJHMG/zMJPTgJaeTgt8z3qAav5dm+thjsQipY6zmULA0z7av61ogmu/zeUF 0ZiltWMFuE4y65yLeMPqwH3fufgPndw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 69F5968441; Fri, 25 Apr 2025 19:03:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DE1CC4CEE4; Fri, 25 Apr 2025 19:03:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745607831; bh=8b1jSipE8vvTKtYxEIerxYV+fQ6mJiSmPoltSWnlsY8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=asHGJjoUtY3RrySnOFcQZSI/W0Kma/L3xi8Pq2sVUQ7Pho6sR15Hc3VCCplaLPz2l SQtHBKauAs6Ern4DTfsAfSUB6L4esqCR4DHL2ILGKodHKyy5L5Z92xKM4lwhuYL6dk 5xZsj4agG3s/us9uLHRPGKCaYALUY6ymNGslA7vSI1HUCTsJIXHdsvQxx2361oPaCR 0gZw/rm2TTBfq1kkj6xRdaFNGUhHtHa8vUDScJKcSYiT6ee3vM3si2InsECmjMmiNW P70X3oUmAQou4jsDl/VIPqcmiEg7XR/3VYS+dBmuEeKaxbaya5Ih3NKlO8TFFgWfAM EJ3qJzwiB5Z9A== Date: Fri, 25 Apr 2025 09:03:50 -1000 From: Tejun Heo To: Harry Yoo Cc: Vlastimil Babka , Christoph Lameter , David Rientjes , Andrew Morton , Dennis Zhou , Mateusz Guzik , Jamal Hadi Salim , Cong Wang , Jiri Pirko , Vlad Buslov , Yevgeny Kliteynik , Jan Kara , Byungchul Park , linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/7] Reviving the slab destructor to tackle the percpu allocator scalability problem Message-ID: References: <20250424080755.272925-1-harry.yoo@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 95DDEC000E X-Stat-Signature: j1oqun5te1nzjc6mz8wnpek97mfshx91 X-HE-Tag: 1745607832-317773 X-HE-Meta: U2FsdGVkX19qDs+7z9ovusikhf5jfqdC32vDsd6vPfOBoQzmIfLt4Fqlw4I2aoXrsB/brEfQDPi9wyt9nnaGYLb+n2FdJ6tfgeauTn8+rha56bQwIp0hrVR/dQqMkSJYTpC8pGUiJcIPb7OzeaW4TUpBY6ucq/UVFILkB0rEgYvou1G2D87JZzc6EfueVXsEv873DCbMf5WE/ZRDykp4BjNMuSvaLTFWm5Q09QS4XskNQHoZFC2ia3Sw0ql1Q7LYPt2yF1AC1RFr9TzwjqJ6YlTJ34fbYpM6V7UH5aPIkhyrb01VVpewefmTLk6duGuKxHoySkeQqwiZX4bmNR36kWXPGyehnrpib3Q4xM2EhVdOHSfwBHdmtdmdIExTgneiwfVGWO+Ot09qMFrttJoiWYIr21BYal74cPubUCJq4O5Dw/s8cg3uA59n/2xtX+72gInDfVPrXKv8Z8yU8Bk4I7MdnXmMXAFsNiyPzuOR38eauahFy/rpZDAgMQLmaBo4rO6e2+UknRpHNRkYAeZhmxRc9ztbthKucJ+JLJNVdhmUTz6Bu7dSoKJill5KW+ZAfeqn1/nYQX+VolLzXoo/napWssM/GF4LM6riROJK67656i08hqV5bpbSEIc8qNqp5WjBOmxoz7+lqQVtIJ4XMbrlEurR8ZCRt/ASzXyyqU/pzTMEc4tx2R7HSI6tdS2MwuhP4JBrH5AoM7vxQk1K9z3ZWHNqL61Nd+8IUaT71Y0E3PUdJJ318CHE43V52oTv5mJaW2fRP0aQAImeirC9g7PyO93dZ70ch8BM85uFb1c1cCFXq+KIPA8iLfeb64xkefYOqiGcwsJOZlmXnS5GbXPlc5LbGzkwBCGcfk1KqU/waJDopXIEP/QAWvEFJ/Bh1IGJfUcl6YVbC4bZH7Eae9/1wayYmCRJcqz1/fHTVYwUDMtV5nvLTZEKxK4EPKk4YCQju8oREYE9Bp7JrBl WUlwLYLg Dss9qrWNw/TR3otr6+xM9dfHkLLTIpQtwBnul3OrPZhTCPdZV9eUoYDM5ccgzcXESZmr2DUbDrgoVSjpaaAHVtNCm5i1XMjgv6eLUmBCIe70QwE423B1IChTItl7rKCQEaBYScnuE4g8o7yfzl78jh65Rq2dXe04wAvQtQBGi14tLkubsnkCGMvjClLIwANw/Yq9hSBJz48cVuB/CyEqzXdCUVpGyE6XLMHU5Y3bmyu6yQCF+RdLgGeZirTjqJiP3KQfP/hTYViQyxuAppnLR6WdEou12uIqIy9ifNMHvFdp86K8GurJYRYTpeg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Apr 25, 2025 at 07:10:03PM +0900, Harry Yoo wrote: > > I don't exactly know what that should look like but maybe a > > simplified version of sl*b serving power of two sizes should do or maybe it > > needs to be smaller and more adaptive. We'd need to collect some data to > > decide which way to go. > > I'm not sure what kind of data we need — maybe allocation size distributions, > or more profiling data on workloads that contend on percpu allocator's locks? Oh yeah, mostly distributions of memory allocation sizes across different systems and workloads. Thanks. -- tejun