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 9F19FC021B2 for ; Sun, 23 Feb 2025 04:44:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEE816B007B; Sat, 22 Feb 2025 23:44:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9DB26B0082; Sat, 22 Feb 2025 23:44:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D654E6B0083; Sat, 22 Feb 2025 23:44:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B932F6B007B for ; Sat, 22 Feb 2025 23:44:34 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4AADD162000 for ; Sun, 23 Feb 2025 04:44:34 +0000 (UTC) X-FDA: 83149968468.10.A8C83B7 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf22.hostedemail.com (Postfix) with ESMTP id 7518DC000A for ; Sun, 23 Feb 2025 04:44:32 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ymqYYegN; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740285872; a=rsa-sha256; cv=none; b=cxzdyaQ3yFITS+5NbfdmF0S2m05CEDWVlN/Gl7iZIyNBegai9tZ7XyYRpLtcmVfx1gmU39 mAqTtLnAX07FCUequLK+aM+UjUGe3+pr222PfStGBHbRgsSialIwkK+TtN11VPTp2/wtU0 dGIiy3JNuqx/rfiatIG7zsV1KSkLqOA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ymqYYegN; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740285872; 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=lcGUFpbUyOauzWV1lBBOTXy0eRR4JvnEyo1klZZ4Yko=; b=6ctutxzyBlsinQlKmYTx+LWF+d+XvLWGEN0fV8BAdD8KiF76IIcXVd4PaEUqZOsPFw14vu H7pYp/JgcQFKTOYXBUL5eVa4uYsg/jKgAp1E+NYl1dBGB/KsyRqLpKZ9G3V7B/sUYz0iTo eY9PeXAyx0Fb1fDbDQB7qKf40pSJuc8= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-471fbfe8b89so308081cf.0 for ; Sat, 22 Feb 2025 20:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740285871; x=1740890671; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lcGUFpbUyOauzWV1lBBOTXy0eRR4JvnEyo1klZZ4Yko=; b=ymqYYegN0C649qEqAEKEkpX4C0HPBzqANP9w1Izo7NeHpckmfD5xR38OGcR2wvEh/f pmrwBZNpyr36d6S1sidlBDvLhUtV0OnemDD96br7Z8JHMfnilvNONq9wjzFQ2DUc02Bi EOsJiqzIcGYyyuND/ngdrgylWvsxho3QQjtRtVHC3Wf3SBsqsn1NCdyFuyRCqysA+psB aIiI1i14XCw+8aGE8rR0gLsWiLuUD/k/lFHqa6MTk85HZzq/3TRA7/PEMhDbIXNRfdF6 F2951l0wv8PKAo/4OSY7pIDnZH27J+OAgJi6DBs1FBLCW8D5opZTLTceY5l4bHV8QmeC /TAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740285871; x=1740890671; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lcGUFpbUyOauzWV1lBBOTXy0eRR4JvnEyo1klZZ4Yko=; b=pMiXQ9aLyFYGpKwh7/50JMvFR855CPu/qoEGpxiCKgWTac9XsQx8XCk8CWhxkvlo/h 807HS+1820J3rKWwCTeoYBG5vYMlclXx/NuNQ1pYtYAe1eyJGHNNohjXCs6x4KUsrrbp jREKDtNHLzjjauh8yKYZNAdHy4vohv5XaDETl/4GBQx4UWuB1Mf07xvaiOvGPafzXO61 07pYB5H3DxtSAFe1khoGKmtDHqadpwSj1cZmJejQvxNy32hCNB8UYUGLN8lUUe9UCRHx KwFCELYp0kL770Kw16mAgcu5m7AClIw+g2cqeDrS9CPgS/967K6hlt1p7XMHcZ6oAHtQ R3Rg== X-Forwarded-Encrypted: i=1; AJvYcCXKwSbJGp5FW7P+E5hTcxM7XkAxv5a669z5jG2B5aKoqLhpHimrteXvhg/nRhliA1US18+rDVC0bw==@kvack.org X-Gm-Message-State: AOJu0YxpcOaXrHIm5pn9xndVS5L4g24LlmHNEkOX7aDydu/lBmDmkQKU cO5H7Brj+OIv10ee5oOgFtwmIKJ0dRcJdGGUP+0Dh/QGEx4KmSVA9O0sSUf4wk88PW9n9jVbly+ 9W54167I0LS1ucggErcCFfzFcTKv6eR58pzrY X-Gm-Gg: ASbGncvpK/gTA19ZaVmuNhPz9f38g4YhXrDKA3JkDbL8AXfS1dyjcu1pr5w8C+eFQdO CcKEwiValmPhWEVuWzNJ4WRo24CI4JHgFOk19aI68zxrWAePAlKl/26dHAinCVN8HetsC1MM5Ms 5+Bl5DeiY= X-Google-Smtp-Source: AGHT+IGb46tw+pVZwQoU1jpISG40+sgx+NO0UEx1OrIl6UCn0VBop6mZKH/321hTah7c9P/9I7sBTdiVFXoipsZ/N+o= X-Received: by 2002:ac8:44d2:0:b0:471:f8af:3231 with SMTP id d75a77b69052e-47234ccbf1dmr2354891cf.19.1740285871140; Sat, 22 Feb 2025 20:44:31 -0800 (PST) MIME-Version: 1.0 References: <20250214-slub-percpu-caches-v2-0-88592ee0966a@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Sat, 22 Feb 2025 20:44:20 -0800 X-Gm-Features: AWEUYZlMNaCB-YHC0BCj5Vx7RBKFda56BzAx84KjKhycsml2Uuiq9n6JJUULhdc Message-ID: Subject: Re: [PATCH RFC v2 00/10] SLUB percpu sheaves To: Kent Overstreet Cc: Vlastimil Babka , "Liam R. Howlett" , Christoph Lameter , David Rientjes , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Uladzislau Rezki , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rcu@vger.kernel.org, maple-tree@lists.infradead.org, Sebastian Andrzej Siewior , Alexei Starovoitov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: kjdtj63j14wpthqo7d65ad714zqnwwjr X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7518DC000A X-Rspam-User: X-HE-Tag: 1740285872-936412 X-HE-Meta: U2FsdGVkX191E5rsiLeVxFG6StpJKsmkKZXy3lmH0eYpkUv/Croxu1aLvIi20baz23k7k1CRuvwzHmDeMtTRSpY5bWZWNUq5dRRQkk5SEvT7vGYD2ajQ3UIjFIP7KpNVcOizj8hJ/GbT8m7rVcjMkhZntW2M53HfGjIl6lYRqZ0jZFb9+4nUoLHiz5m1UJXkS5Ks/PFUvBb44WwmFYzXSO7Y0W860Zu7HNouaTX3gO3D91jnhwvXwy6kVArtgnI6eXkVdoJ5iJwu8FlSew5shiWEmFWnTQyHlLxAHeEwwaShzYhx8K493+1vjCentpCdphR4DqDhsh++/lpbD3osCupFndqjF0TECjqzrvlBFBjk5wRJL/WutBSsDUe6QnsADMHgbzfOKRAVysla1/U9n2HvK53V2EYf3qoZWmdo4jSdSOCmQjJOWz7/lGbDAVUPxXcpGA3KEtRPAhnONNcJATT/7Gi9+o6dSSbcCi9vLJ0o+H9M9IiSC3yASGS8jwtFysSCp5Oc3L0itxLZjgYMFAxZDfqONdR6k90OPsRPi3WO93igRviLIXVUuvvCuYwvQKz/HKsU9MVzVf6c4K+1mIG/skGJBv4X4nocIqPV1+YtgQ/Ew2ueZJTBqxJHYrpOooRJQCJ/7gNPG61rcs4W96RDMgijno8e+T0lPx1S1IDn3onZrkTVBEBFhtuCtTqoeBQ7mxvgZVOmnH6CVGhBYFJf85MOm2W6TnPphvQIHskGQhTOBM02/QZi7SWSF1vhIKqtxNXGzZF2qeBlEko4gLE/haofIzmL2ZL+gTRUTljkLuZlMR7J+L0TqvaKL1DHCfJm2rMzZo51Sgg1hnWyhngtgl/AeNz4ibA5quwn2D4Fd4UCY3HRy0puBq77FV3KfatFUIvfBHDRNuVNEDAHZJi4P/ikJ2x9012HAOOyuwaBm2P5q+z92QZegHDXc6BUhyrf9zABunqto26/3KD 7inPbkUG Fqd2/mVVUBblsqJz817UOxGyzpmtYg94pafFPrX9bqqIjwxSq7N2yeknuWNBl0rU5VC1GpKvKQK6peeFyKIGxQH5U48oT07g3OtCOL0exEBupHtw8vHG135abVuxxF6Nsekf0mWytZd8F+8zEgfSYLaXDCj22JyUIVlGHOnKszZ+IyhmTPneoa5/AjCI64Dw7td6jaC5vXnbZlWsHA1UaIQAmgI9fdhxc0Jh0sGn5FNUjdAglFvAZ3j2GgYSzTc0DqiKaCxojIHM5sLM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002446, 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 Sat, Feb 22, 2025 at 4:19=E2=80=AFPM Kent Overstreet wrote: > > On Fri, Feb 14, 2025 at 05:27:36PM +0100, Vlastimil Babka wrote: > > - Cheaper fast paths. For allocations, instead of local double cmpxchg, > > after Patch 5 it's preempt_disable() and no atomic operations. Same f= or > > freeing, which is normally a local double cmpxchg only for a short > > term allocations (so the same slab is still active on the same cpu wh= en > > freeing the object) and a more costly locked double cmpxchg otherwise= . > > The downside is the lack of NUMA locality guarantees for the allocate= d > > objects. > > Is that really cheaper than a local non locked double cmpxchg? Don't know about this particular part but testing sheaves with maple node cache and stress testing mmap/munmap syscalls shows performance benefits as long as there is some delay to let kfree_rcu() do its job. I'm still gathering results and will most likely post them tomorrow. > > Especially if you now have to use pushf/popf... > > > - kfree_rcu() batching and recycling. kfree_rcu() will put objects to a > > separate percpu sheaf and only submit the whole sheaf to call_rcu() > > when full. After the grace period, the sheaf can be used for > > allocations, which is more efficient than freeing and reallocating > > individual slab objects (even with the batching done by kfree_rcu() > > implementation itself). In case only some cpus are allowed to handle = rcu > > callbacks, the sheaf can still be made available to other cpus on the > > same node via the shared barn. The maple_node cache uses kfree_rcu() = and > > thus can benefit from this. > > Have you looked at fs/bcachefs/rcu_pending.c?