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 777E6C6FD1F for ; Wed, 22 Mar 2023 12:30:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D93396B0071; Wed, 22 Mar 2023 08:30:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D40D46B0072; Wed, 22 Mar 2023 08:30:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE1416B0075; Wed, 22 Mar 2023 08:30:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AB9336B0071 for ; Wed, 22 Mar 2023 08:30:43 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6C87BA047B for ; Wed, 22 Mar 2023 12:30:43 +0000 (UTC) X-FDA: 80596467966.19.5F6DF3A Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf29.hostedemail.com (Postfix) with ESMTP id A3B3512001F for ; Wed, 22 Mar 2023 12:30:40 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hwEVw8FN; spf=pass (imf29.hostedemail.com: domain of merimus@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=merimus@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=1679488240; 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=hIDnRaN9sxd0xnZDEDrl7FwoOB+6T8A94tkf+oMcNsM=; b=z3CQ6JMqTbfN8N/RMtcPDOjAgroTFHjujCBwdQfdRyhRYZ8ixj6nclTqS/QV/vEIyjQri5 5gfxjD49ZLPKZ4Suqdt3+ae+XiLUQ0Btkc1RAmNUYpXXUViWygu7j6wtvr32QGeVOjjeBE E8/Gq62mYWQjtI+jkmU/vwltNJNji5k= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hwEVw8FN; spf=pass (imf29.hostedemail.com: domain of merimus@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=merimus@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679488240; a=rsa-sha256; cv=none; b=IxocDjbHoV2CVK6IYqaYrVhiIrSpUvQvQoJy3upF3aNISr8j5QANp/S1odvWrtlHbE/DXL DF0buiMlAl2XJ6BB5ppMsxepfXIGsHOTWmU5i5dTHGxw/3+X7IbUu5VNjarWWNFyr6m7xQ xPzbow9fINHGOiH280CjEmuwo76SJrg= Received: by mail-yb1-f173.google.com with SMTP id s67so3930005ybi.5 for ; Wed, 22 Mar 2023 05:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1679488240; 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=hIDnRaN9sxd0xnZDEDrl7FwoOB+6T8A94tkf+oMcNsM=; b=hwEVw8FNtToCOmLQzJtRNJ/OkEWC4Dguci+blmJcuw5u2JD4IBIE2+21El8yJXYoS4 xuyDJwhGLwfaZi4e9bgZZGHhFGtOICW8hbt23BhzniyCEPVGOXnYg5c3h5ZbYmsCAqzr Ul3z2M8L2Z/jcy8nHggkc/OqzRO00lMvkcrhcmAvsTir82DbqXUWHEi1I0pl9naV+vso //rUba+Z/gTIow6PImoH69N7wZehEHDn3oDGDLUfWuVliKEdajCUSZwA9E/tNQddm/fB YJA2gkwEYdZDmOzm1TMbsjMExHS//8LA6sjV4vQxVz+tjTXv/wXuRWBAxV6D3ze4hQfa 7+rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679488240; 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=hIDnRaN9sxd0xnZDEDrl7FwoOB+6T8A94tkf+oMcNsM=; b=ogOXkW55pC00BUmz6rbvphWuO+xs1BpR7FcN8FEakkx2d3iIBBOzGLkoTpLNjVHKhB IUaf3c+1TgLkyDlvH/BzSwirdJkuKQe3k9EE6jkrzogKQkheGoUI5OPgxZLkovWnwMv9 62V5Wx0z/ZAXZta0QhhiB4MbTQe+Gkqbpvf2PJ6t1H4lwGDsKFdUP0udutgaWgmdv1d8 tEfAqV85mnX4qf34VtTb9HnJD7z3P7Wl1h/dccDX/QOi2Zp2EoRiJY2gdVAdCZAbHddy 8oALYJ0kq/q5I07xhnKeSI/9TxHaPhXXrVQ8xP6US9ujTW5z6DS0FcLy4Ji3byFhAVla fIUA== X-Gm-Message-State: AAQBX9dksLZ30RPEdQ1Gi2073wxV+rJNPwMlh7CC477EQCXYgyKW4JZH NAJqXxwLrcrtxDTCFGyaZT18ttlNxnV7MElLe/FqvA== X-Google-Smtp-Source: AKy350brVrs9DIoKaxSl5+ZQ+gEXyG50JHgNzUqBm/HoXTIpFkpBjkTYSzxIQd9ZikPcfWRmDPMlyrDfrlfnAJgtd8I= X-Received: by 2002:a25:d256:0:b0:a3f:191f:dfb4 with SMTP id j83-20020a25d256000000b00a3f191fdfb4mr5148818ybg.58.1679488239630; Wed, 22 Mar 2023 05:30:39 -0700 (PDT) MIME-Version: 1.0 References: <4b9fc9c6-b48c-198f-5f80-811a44737e5f@suse.cz> In-Reply-To: <4b9fc9c6-b48c-198f-5f80-811a44737e5f@suse.cz> From: Binder Makin Date: Wed, 22 Mar 2023 08:30:27 -0400 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] SLOB+SLAB allocators removal and future SLUB improvements To: Vlastimil Babka Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, bpf@vger.kernel.org, linux-xfs@vger.kernel.org, David Rientjes , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Roman Gushchin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A3B3512001F X-Stat-Signature: nyx1misrtwa5979a4zjoz66bebhsw518 X-HE-Tag: 1679488240-235454 X-HE-Meta: U2FsdGVkX1+3rPRg/uVFT2/FQycxbowCio+m7cBpDyYwCuH4jcrTvM1J6KVZ67k92Kx60jg9ZjRgo1YS3scr/HEBvHriKpAH2Hka/fTYf/Ni0m1yF6l8h9h2Nnf2noSK9Nw699G6WKDi5xsFJfe2Bo8Mq7GeJsS4/LIibOrF/0tUOznbdM4cyE0Vx/2MfB2Klo8SS4IRYw02g6opUZS9NNKUT37/y4QZVLcMgIdoxhjykSbfe8hba5k6O3wC0NlEXPdVhgQl9VCcbFUaQ+qMvilFrZM7/KMBjy1aNRCJ1iTEblqF8utRQA+Orf/YFl9Wwz+UYbnLfpiJM+mHmCcRR46qhSQC9XNrfVY1aP9UVJyLsNX9wLcGjR34NJ8uPgCesPFapL1+TG6B+kos5Hm4U3Mlbc48kSvrhak3Uu2KV5UT/z5f3Mb56+15H1OHQcCXLHeMjIYbU3CENY4hUEy9bd9KI51i07Vrv5j7N1kkYlFIxLv1Z7u7LqJeEe4eMeLWhOdLkCLxQocqtmauGmRT+Ilni8JxBdueXlaRhajWgfvpr9YnB/6MW2CkmEBeomQal9ayUZdn8tc6I6JkIiQPzGoYL+7mVEECr9oCM6paYjaksFHx1aWQNIb+CsHjmIV1J4y1tUDna7X7Lk2jAbMZrpKfO2IrntQQMy51xqn7kuNLYxOxmMdMhT9yzTU8TGsMtBVLx278j228XBf0Z6HcqEhcNFEJhD84+VSqEBYTAC8w2eEV8i2nJYdFAjXE7Q673HroRowbxa8fA/n7n/VSFL7SN4WnVWSjg4vXYXQtKRL5hcTNx73iw3PX7suJbU8+hoDEcjjAvwjgy11fl6t5HVhlVuYu++9PWIE84GDQ353lcoblb2NBBjwCy/0feN4JBna/Aa0uku5iuZBzxWY7LCPUZQCmLuJfingpA2zBq3NJ3Xv1DtKarhdDSOx2TGEDVTZKyoe0NZFQ/EJAxcy gSdm9bRd 6kzmoNebqxWWh3LPHLAlfxnWOEbWPbt0zkUFoEQp3fIqHMoNYRRhu+kt2mCCVSZ/fe4o4dbzpt4uU5coNzf8gxcWtdebvd7pXvhBRenCV96mZ6RTfo50O8dRfyaSLCGCRN9hplezNVExoZih+gi41JkSEFmasdPLdglIDYWhjwBQipAP442hJRC4t2zUKWaiCiPF1kXSPTqcZ23zCAIDR9Afd4S9xRIM5Aq6sdA923755pzh6MZoDuz/ny50O8YtEfndOq9OKDiEhwJFBQsOaOH8ambdhW3/7k9G9Qw94rTWdcU33S0goqIjjRA== 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: Was looking at SLAB removal and started by running A/B tests of SLAB vs SLUB. Please note these are only preliminary results. These were run using 6.1.13 configured for SLAB/SLUB. Machines were standard datacenter servers. Hackbench shows completion time, so smaller is better. On all others larger is better. https://docs.google.com/spreadsheets/d/e/2PACX-1vQ47Mekl8BOp3ekCefwL6wL8SQi= v6Qvp5avkU2ssQSh41gntjivE-aKM4PkwzkC4N_s_MxUdcsokhhz/pubhtml Some notes: SUnreclaim and SReclaimable shows unreclaimable and reclaimable memory. Substantially higher with SLUB, but I believe that is to be expected. Various results showing a 5-10% degradation with SLUB. That feels concerning to me, but I'm not sure what others' tolerance would be. redis results on AMD show some pretty bad degredations. 10-20% range netpipe on Intel also has issues.. 10-17% On Tue, Mar 14, 2023 at 4:05=E2=80=AFAM Vlastimil Babka wr= ote: > > As you're probably aware, my plan is to get rid of SLOB and SLAB, leaving > only SLUB going forward. The removal of SLOB seems to be going well, ther= e > were no objections to the deprecation and I've posted v1 of the removal > itself [1] so it could be in -next soon. > > The immediate benefit of that is that we can allow kfree() (and kfree_rcu= ()) > to free objects from kmem_cache_alloc() - something that IIRC at least xf= s > people wanted in the past, and SLOB was incompatible with that. > > For SLAB removal I haven't yet heard any objections (but also didn't > deprecate it yet) but if there are any users due to particular workloads > doing better with SLAB than SLUB, we can discuss why those would regress = and > what can be done about that in SLUB. > > Once we have just one slab allocator in the kernel, we can take a closer > look at what the users are missing from it that forces them to create own > allocators (e.g. BPF), and could be considered to be added as a generic > implementation to SLUB. > > Thanks, > Vlastimil > > [1] https://lore.kernel.org/all/20230310103210.22372-1-vbabka@suse.cz/ >