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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6344CC433F5 for ; Mon, 4 Oct 2021 06:01:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D2B3D61378 for ; Mon, 4 Oct 2021 06:01:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D2B3D61378 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 36BF36B006C; Mon, 4 Oct 2021 02:01:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31BEA6B0071; Mon, 4 Oct 2021 02:01:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E3806B0072; Mon, 4 Oct 2021 02:01:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 0BFD56B006C for ; Mon, 4 Oct 2021 02:01:16 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A9CFF2FD85 for ; Mon, 4 Oct 2021 06:01:15 +0000 (UTC) X-FDA: 78657707310.38.4E65535 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf28.hostedemail.com (Postfix) with ESMTP id 6BC89900185E for ; Mon, 4 Oct 2021 06:01:15 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id y1so10333019plk.10 for ; Sun, 03 Oct 2021 23:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=cxuoqPc/PmB8mcM5TuGRV+qu2o9l2KtFKmqxX/+Qr9o=; b=qgQrtCEaMYgsg0jjCV1DDo2tvrEUcH4DzPaBi8qTujHdIdAXmDgIa1Po8Z9Y9NuDj4 hub+B+0tOawqxcXdf8mQB+5Ibl2uOqRE7Xks92k1DT7OH80h2vr8Pnmdd2RHxEIIUfEC g9Oge8Ue60JXR+sVdeFspouBp+L2LcxKkm9J72waXhHQro/RkibqFKisL1JtzBjeTaa+ PCG+vGytmcfNgAaWuBXkvvo6Sa00J2R5VC9L3g2HNV4sO/9TvHNsSfwBoF+HmrEXWJ6W ttnHIF4qa6bGEn/ZP6XTRMykasTrS+g0Gb6/+Rj8fMt5kZx9qnU82cQQK8JGDN6s19w9 EfXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cxuoqPc/PmB8mcM5TuGRV+qu2o9l2KtFKmqxX/+Qr9o=; b=keSxLcY/GHpdHPk00LeBqlf9KG9Z7CVVyrGJWPfXs8sDJiFO8BLp9p21dTvDrvdZS4 oi3FSZDN3Chf/0UQbxljgLyuvHSUbzcfBIGFxkiRWBgZNLSTFHFbExbO+Ppu3O4b93I+ iFDr94RodwiJqMx3VvO4FGbXBYtMjWpgTbFFP6dBGeDuOTqyfUA8u0mEcI7YOc6s8eBY eI+L0rCVJmjzQTNO4Q9PmjRc+jHz3QFKrbh/pP4wzZAk+DY2j2VdO3WxnnNHzZ4H7BY3 KNX+BTjacQUJjAQIT7AXQA61aocbBzPJaYXpJTvOViRI2lKtquqWnrlQElYX35MerAVM amEg== X-Gm-Message-State: AOAM530AXk7qV+2DqJ79SSVdCIThiXwfnP3DA3YQ8Y28bG+WjSgrUChI r3MrBPyLBzp+2HVtlCCh3O0= X-Google-Smtp-Source: ABdhPJx+aSxo9lpIz8K+5iM+BjVf3OcTZG4Ob8vcG7A2msOIc7Zog6MPuLNVDe32SA2/LfMsASfHqQ== X-Received: by 2002:a17:90b:1e02:: with SMTP id pg2mr35298336pjb.114.1633327274431; Sun, 03 Oct 2021 23:01:14 -0700 (PDT) Received: from linux.asia-northeast3-a.c.our-ratio-313919.internal (252.229.64.34.bc.googleusercontent.com. [34.64.229.252]) by smtp.gmail.com with ESMTPSA id j6sm12257166pgh.17.2021.10.03.23.01.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Oct 2021 23:01:14 -0700 (PDT) Date: Mon, 4 Oct 2021 06:01:09 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: David Rientjes Cc: Vlastimil Babka , linux-mm@kvack.org, Christoph Lameter , Pekka Enberg , Joonsoo Kim , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [QUESTION] is SLAB considered legacy and deprecated? Message-ID: <20211004060109.GA2949@linux.asia-northeast3-a.c.our-ratio-313919.internal> References: <20210927090347.GA2533@linux.asia-northeast3-a.c.our-ratio-313919.internal> <8aa15f4b-71de-5283-5ebc-d8d1a323473d@suse.cz> <20210928111231.GA2596@linux.asia-northeast3-a.c.our-ratio-313919.internal> <20211003055928.GA7643@linux.asia-northeast3-a.c.our-ratio-313919.internal> <377a622-9a5e-37dc-8f8d-42ae124042b6@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <377a622-9a5e-37dc-8f8d-42ae124042b6@google.com> Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qgQrtCEa; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6BC89900185E X-Stat-Signature: 5xyuocqbaywo571eycsbcugdh9c1djyu X-HE-Tag: 1633327275-998183 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: On Sun, Oct 03, 2021 at 06:25:29PM -0700, David Rientjes wrote: > On Sun, 3 Oct 2021, Hyeonggon Yoo wrote: > > > I think the points are still valid because on some workloads SLAB works > > better. especially when alloc/frees are intensive, SLUB tends to become > > bottleneck. > > > > If we can't drop SLAB, it should be at least maintained :( > > But it has been neglected for a long time, which makes people not to > > use SLAB. Nobody likes to use a subsystem that isn't maintained. > > > > Anyway, I'm curious about share of SLAB and SLUB and on what situations > > SLAB or SLUB is preferred. that information would help maintain both. > > > > Thanks for raising this, the discussion is always useful. Both allocators > have their pros and cons. > Thanks for kind words, I was curious and wanted to help improve SLAB > I would disagree that SLAB isn't currently maintained, I think it's > actively maintained. I thought it was not actively maintained because most of patches were fixups and cleanups for years and as Vlastimil said, new features are only added to SLUB. development was focused on SLUB. > I think the general guidance is that changes for both allocators can still > be merged upstream if they show a significant win (improved performnace, > maintaining performance while reducing memory footprint, code hygiene, > etc) and there's no specific policy that we cannot make changes to > mm/slab.c. Good. I see things to improve in SLAB and want to improve it. I will appreciate if you review them. Thanks, Hyeonggon