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 9A9AFC369D1 for ; Thu, 24 Apr 2025 18:47:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 657F76B0023; Thu, 24 Apr 2025 14:47:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6063C6B00D7; Thu, 24 Apr 2025 14:47:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F6546B00D8; Thu, 24 Apr 2025 14:47:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2E2F36B0023 for ; Thu, 24 Apr 2025 14:47:08 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7D3DE121926 for ; Thu, 24 Apr 2025 18:47:09 +0000 (UTC) X-FDA: 83369819778.13.89CCA5D Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf13.hostedemail.com (Postfix) with ESMTP id D81282001D for ; Thu, 24 Apr 2025 18:47:07 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MFkInMrC; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.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=1745520427; a=rsa-sha256; cv=none; b=11Xeek+cFTQZFijAmCLVNWv/dIIGMs7zmfDZrSFj8zqcke9mucPOhlBjp7Sk4t754yznAS FWZxhuvvmyI3qIVuofkj5WARyA3wsFMRqS+AgQrP1RYRBCVSlQN3crv4E7uwp+x+EKYjYO Z/cGGC+geNd4nKWxL/l8QMGY3watjkI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MFkInMrC; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.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=1745520427; 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=m0M084L7oG+e7tXH9Mz7OPug898R4BAyrJHrMCYRKWA=; b=VFu/R/au9+1O+AT/HbOzYZx8JPQWhj3VLUGWIRpWbwjfpsFowhlJiYuqb9pBsGWuQ7mpCC GwZALg6Ix8x70rFgvRCcxWYFgdB9gvPCfhVlWvL1Hozulp5oOlP3DXePT6Dxyk8g2J9xIv fEQYBBgbw4yJOjxE2qfCSI195+vniOk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5CBFE6845A; Thu, 24 Apr 2025 18:46:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0A39C4CEE3; Thu, 24 Apr 2025 18:47:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745520427; bh=63B8SOezIjHF6IjNgkPDhala00PxbRTVS/sNnyV2qkA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MFkInMrCO5J8iV/bB+T5cQR/lWofnjsGp9pDGEQWS0+81n3snP5Ijg/Jzni5NyqWE bL9nG5a2dQXEVaIviUZd62Clu7xK+rrOC42TCEbHp6KudOiK0vnD6H5Ro6tNa4khia FA0o0nYN53RVzARWd6Vc5Ndiehh4pxY7myVX05xhVEvrY7VwlNOR7NXCdpx1r0Xhty hDsRG70+dZhnKvCQyvhLU4agi4SEjB7dK7r/RfOdRBGh56oV90iNaEfMnBmV8xELA2 4Ll1s6QcC295oO/zrY5exdGJW1WvIKXqmCtN7TeVeQKP1B7sHoet+vrBGAVLTg2MyT 7LFKLShA+9KLA== Date: Thu, 24 Apr 2025 08:47:05 -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: <20250424080755.272925-1-harry.yoo@oracle.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D81282001D X-Stat-Signature: 7uphrxgwexajtqstmp15d5c73raos5yr X-Rspam-User: X-HE-Tag: 1745520427-13227 X-HE-Meta: U2FsdGVkX1/3CdGCaSGkHtKYjPfpS2+TXszgPtOgksue+Lc5U/SFgtrIvsdU8n6sn3yb/HitoJLlSkOJ+kPVeERPicILhdDWhckNjkVqvt0teErFs0PPNCzTT5tX9VKGSNQZI0xcdZvSCq8kg/ImPIj67xLcah26MlMrfP5+K0nTlbu0xvb6SgcG1kek9CmLNlC1G5aWrGE0s2lncv3zM4n1Em3uvYbiIWL3NK6xrcbXHiy23uhlg7MvlPCjpE33gNItKbUawOdExy5B89EaI2AAX4C9gfadnkhg5HQLnVcrULlVNftWwm7zIQj/0d4JquesGA82rUYI3bnjMcjzIzPZkiJ6MjGPgS2Cv8yz4prkqATnt9faleCmwC/Xb8A2dZS6oMxyhbOz7unS041IqyIustuqcmPtqbClvnXc5iBIkDJyGNTc+59VaiMiAot7rgwnzI/oXGyD5CLs6Tb4S96E3SbiewZntsebHYiUNfhUtKUuhOJjbYU4U24fc2Lk3xDM8kZyrMNB5mAAqO5IyaDHjGeLA4gyzckeUe705Xs1S1o+WuvT+9MRbLQX4zHWw/DRAYKVDFSwyW1jHF/s8jfHptAgGDPnwxZYjzsg3hBiioDgvzs64SVXVOaEaldfIGvkE3/2Tl/TkecPYdxVnVSYEcptMoazZt9sx/2GXDqoANVyjPWHxR8rDW8JlggQ++LDrKsbvIeXHCMUKKg9ZScuiywgLMfCuZddJVGKTUwruhGd3TYpDJ25biztx4F4TTLH6evKljgFBz9gSDZKpm+Q3hPdROLLxZdQevOnF6JS8PIZ/OQ3A395lwgRQqZDnWSunS1lj80PLLcnAd3/h9l5nDoiOIb2r+0FNdg2rOsGOE/9atRsNbtBP9GDZYlOM3NSGM1Mr1VZzp/xSIudQ4tfMjKm9+pvUGmUWujQv0sbB73eZ2kAp6lH9i5+O3UfI833y/skXHTiUDx++iw EWqJTqOf 61Alvt5RO6G0a3PGhE6TiHM2USqHCqmRlB8jIT4GdWUCutj6xxiMxsD8BYEonn78wi9zxlZ01j0EuGKgrQTbzSYoE2Yx7EXrHL9hroOA+tvd8dA+/y2Dyl46m8nMSrQf2DYAHaX68lcJOPUd3qyL9l9yoJ+wLu9whL8r1t7JmZDFvCXdZ/W+Z9zRbSNOBPTPC7iR07ApzHTyvt7Q4fM7Bbt1y/6wlNsY2VYUvgTeYrIH3DUbGHlnAv8qCiQsWkc7N/uiPNqwZH+G01SNvv+vcn08EYiDWfBhWniY6vasbiXwN/ocwsWx4dWZ3Rg== 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 Thu, Apr 24, 2025 at 05:07:48PM +0900, Harry Yoo wrote: ... > Eighteen years later, Mateusz Guzik proposed [1] re-introducing a slab > constructor/destructor pair to mitigate the global serialization point > (pcpu_alloc_mutex) that occurs when each slab object allocates and frees > percpu memory during its lifetime. > > Consider mm_struct: it allocates two percpu regions (mm_cid and rss_stat), > so each allocate–free cycle requires two expensive acquire/release on > that mutex. When percpu allocator was first introduced, the use cases were a lot more limited, so the single mutex and expensive alloc/free paths weren't a problem. We keep using percpu memory for more and more things, and I always thought we'd eventually need a more sophisticated allocator something with object caching. 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. Improving percpu allocator in general is obviously a heavier lift but that may be a better long-term direction. Thanks. -- tejun