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 8BE97C001E0 for ; Sat, 21 Oct 2023 14:43:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D9758D0022; Sat, 21 Oct 2023 10:43:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 861F48D0008; Sat, 21 Oct 2023 10:43:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 703898D0022; Sat, 21 Oct 2023 10:43:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5C8A38D0008 for ; Sat, 21 Oct 2023 10:43:50 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 295AF4045B for ; Sat, 21 Oct 2023 14:43:50 +0000 (UTC) X-FDA: 81369737820.13.EFA0F97 Received: from out-192.mta1.migadu.com (out-192.mta1.migadu.com [95.215.58.192]) by imf21.hostedemail.com (Postfix) with ESMTP id 6297C1C000C for ; Sat, 21 Oct 2023 14:43:48 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Fls0l9YR; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf21.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.192 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697899428; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=/hOjdlwNEQqgIxIEMteXsYoxVv+s7eBpX1Ru6VaIia4=; b=MbYDZH3dBthPDCjAlKNpb+/p0Rlw08eDgDWL4Pcyi6Y/E9k0mhzuzwqCH/7U5LbYzTK1jL +76EXOQse0flsslzrEuUoTz3UPWbk0jY3O9b4Ldl9kQD1SY6OsTIbIdtdz++/bTO2iHwga y1PrpbE1ftLEaG2o+i5i6pvMeU+7sQ8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Fls0l9YR; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf21.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.192 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697899428; a=rsa-sha256; cv=none; b=8Jnq+vodUI4y9g5Mbd2wJ5JDNlByVTOL0um8Otze33Aw+8SxGX4WJMe8dMMk7IU1wCgEnj r7dgxOepzL2KG2ESJ0+CLYJRsSG+Hgej2sVw3KtPogTfh3LBDien1fq6xvOI7zvdPEc865 ryuyIpUtMjWZ1k8bkFMb8REYMvL4Cmg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1697899426; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=/hOjdlwNEQqgIxIEMteXsYoxVv+s7eBpX1Ru6VaIia4=; b=Fls0l9YRtgBOwwpecRoQqTQhprO/dtCHv0ZscJf/Bn+Z+gademQog258E1yBYSvxc9ocig 5xMQaZ6Co/WaOgoXlVH0k/oqr1tvEGzlxnsWBDziTBMuxS9VRgNYM+L3vp1JnBQZpxQubX fjY9Pi1ViHfs7TNpXqKXN7YkCV+s/tI= From: chengming.zhou@linux.dev To: cl@linux.com, penberg@kernel.org Cc: rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, willy@infradead.org, pcc@google.com, tytso@mit.edu, maz@kernel.org, ruansy.fnst@fujitsu.com, vishal.moola@gmail.com, lrh2000@pku.edu.cn, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, chengming.zhou@linux.dev, Chengming Zhou Subject: [RFC PATCH v2 0/6] slub: Delay freezing of CPU partial slabs Date: Sat, 21 Oct 2023 14:43:11 +0000 Message-Id: <20231021144317.3400916-1-chengming.zhou@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 6297C1C000C X-Stat-Signature: 6xux154z4gxyjc4u9765sngzfppjj1fn X-Rspam-User: X-HE-Tag: 1697899428-20376 X-HE-Meta: U2FsdGVkX181Qh5ZV6knWHmbhXQayKL6uuK/J34BMb+edeI7lyQbe/UFE21tKy1/7onXSWpTToMX8BSyx7qqCElReBUGPjF1Hk2JnzpDwgWnmPq1do5YJOaORhwM1I7wFSAiVtGtcE85f8UzjhfekpBpr3Iawfo0QYIcp8BWWfOMI9HPDlxqlRZv8ZZOCPDS8Rlb+vo6P7y4ePokqz95RCeY4NcorPj0T3N6LYRTfSTYr+fuWmOnVbQSpUlWzf+3XM0ICBlhS128yZOlcoeQVw/HB7XAubyLN1nBqTUnmHkra6OR2J0atyU6zMn5ikzYW0ce+j4vYDrbgy2Gq0N+gTcXk1U/nU8N/lAahNelgkZA78fBxO0dO2okiExGIb0+PgxkaeSVr8rXU1HYK+y1d3fITnnFppW37JGAzkajdGGh3PhpFtjCGnrGdGOutZpYhsHxvvslUO5t5k0D7pu80McNfp6hpGQsB+Dm8MYB0AhDc3K6PNrQNhPB7o2/LOL7Lb0TPHnjShIFugLrTfjh9w8bExarCB2rolY66SjP3etwC5NKQqdmodU4hevMfxQcbLGgx0XXJDT3SQc9FkzRG+AkzW0mb4stjvAHNKK3CAFHbO6TEC9K2vQg15hXkjQxjZm3UXbZaW8RDrQTn9JZE8za49x6EyXaGWJj9RL++QSVrO4Z3Lpy+NyVSodeh/ME1qvO5P8exe9IgprNmunmt1fpd/c67Z45naJRUoMxUxQn4g9Z8djrDEmVbS0X+szxjIjS7xhOi2iRoRH7PK8rUItVIQ3X7/YvhAsE/Xma1Ak0yqw51TFtU0EuUBe0VKF9hxVPeXGIFtahyc+WwCjkzhLVzaXDrN1LLBfdQfUUQ5cT683iM6G8ArBmOCXXJt4Z3YCn+zcwrbXmcoh7wkCiWW+QJ3dmAeadkge0ODCbq1QCPS3ppGU4B9UTcRuSLJRChypfi32+E6hmUhM6oHd Zjb9OZq4 LhOb0ovQgA5WMUq8Nh3RaI8n7I3o0isQlAysp0BC74CGmcSky9VnN9SH5ltKE3cJPYMriHPlCadpawuD1dzrDBI9OM3WVF3WLhIIwl84kpQGYjMKx4bio35MhhUQek7qN7vj5pkCyXG4pVHHl05bHDfpXKR0HuJw9g8CE/wvayhpLfTTlkdXbjAkJBZ3Su0kOWD0iaxxGbOZ2SuON07+abr7k7G9AWT50of38zZfuXc4pMrAPsxGi26Hyyj8B/hxVjV8fBUSpOaUKw50= 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: From: Chengming Zhou Changes in RFC v2: - Reuse PG_workingset bit to keep track of whether slub is on the per-node partial list, as suggested by Matthew Wilcox. - Fix OOM problem on kernel without CONFIG_SLUB_CPU_PARTIAL, which is caused by leak of partial slabs when get_partial_node(). - Add a patch to simplify acquire_slab(). - Reorder patches a little. - v1: https://lore.kernel.org/all/20231017154439.3036608-1-chengming.zhou@linux.dev/ 1. Problem ========== Now we have to freeze the slab when get from the node partial list, and unfreeze the slab when put to the node partial list. Because we need to rely on the node list_lock to synchronize the "frozen" bit changes. This implementation has some drawbacks: - Alloc path: twice cmpxchg_double. It has to get some partial slabs from node when the allocator has used up the CPU partial slabs. So it freeze the slab (one cmpxchg_double) with node list_lock held, put those frozen slabs on its CPU partial list. Later ___slab_alloc() will cmpxchg_double try-loop again if that slab is picked to use. - Alloc path: amplified contention on node list_lock. Since we have to synchronize the "frozen" bit changes under the node list_lock, the contention of slab (struct page) can be transferred to the node list_lock. On machine with many CPUs in one node, the contention of list_lock will be amplified by all CPUs' alloc path. The current code has to workaround this problem by avoiding using cmpxchg_double try-loop, which will just break and return when contention of page encountered and the first cmpxchg_double failed. But this workaround has its own problem. - Free path: redundant unfreeze. __slab_free() will freeze and cache some slabs on its partial list, and flush them to the node partial list when exceed, which has to unfreeze those slabs again under the node list_lock. Actually we don't need to freeze slab on CPU partial list, in which case we can save the unfreeze cmpxchg_double operations in flush path. 2. Solution =========== We solve these problems by leaving slabs unfrozen when moving out of the node partial list and on CPU partial list, so "frozen" bit is 0. These partial slabs won't be manipulate concurrently by alloc path, the only racer is free path, which may manipulate its list when !inuse. So we need to introduce another synchronization way to avoid it, we reuse PG_workingset to keep track of whether the slab is on node partial list or not, only in that case we can manipulate the slab list. The slab will be delay frozen when it's picked to actively use by the CPU, it becomes full at the same time, in which case we still need to rely on "frozen" bit to avoid manipulating its list. So the slab will be frozen only when activate use and be unfrozen only when deactivate. 3. Testing ========== We just did some simple testing on a server with 128 CPUs (2 nodes) to compare performance for now. - perf bench sched messaging -g 5 -t -l 100000 baseline RFC 7.042s 6.966s 7.022s 7.045s 7.054s 6.985s - stress-ng --rawpkt 128 --rawpkt-ops 100000000 baseline RFC 2.42s 2.15s 2.45s 2.16s 2.44s 2.17s It shows above there is about 10% improvement on stress-ng rawpkt testcase, although no much improvement on perf sched bench testcase. Thanks for any comment and code review! Chengming Zhou (6): slub: Keep track of whether slub is on the per-node partial list slub: Prepare __slab_free() for unfrozen partial slab out of node partial list slub: Don't freeze slabs for cpu partial slub: Simplify acquire_slab() slub: Introduce get_cpu_partial() slub: Optimize deactivate_slab() include/linux/page-flags.h | 2 + mm/slab.h | 19 +++ mm/slub.c | 245 +++++++++++++++++++------------------ 3 files changed, 150 insertions(+), 116 deletions(-) -- 2.20.1