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 A2C60C433F5 for ; Mon, 4 Oct 2021 14:22:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 49B5B61215 for ; Mon, 4 Oct 2021 14:22:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 49B5B61215 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 D865A940032; Mon, 4 Oct 2021 10:22:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D355194000B; Mon, 4 Oct 2021 10:22:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C252F940032; Mon, 4 Oct 2021 10:22:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id B329494000B for ; Mon, 4 Oct 2021 10:22:40 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6FE1A30C76 for ; Mon, 4 Oct 2021 14:22:40 +0000 (UTC) X-FDA: 78658970880.10.E7E4EB5 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf20.hostedemail.com (Postfix) with ESMTP id 21C17D001BBE for ; Mon, 4 Oct 2021 14:22:40 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id s16so14678056pfk.0 for ; Mon, 04 Oct 2021 07:22:39 -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=G9ezp7evjOZKJ358P904p9qdWMlp+LXB67WAKDUGAvU=; b=fDVZp6zUdjdIrAJ4sxqkNxQwpOBzbMrmRJKzHx1YIV96EQzpOKrz4oAL73lx4ohBOK HSZCs/pdurVBOY01RbN2jVygRzzFwLNF89CI8gL0Aa+uC7NgFKuEK3fkLGvj6a4khyjd s8LBkUGKzgjAYEfCQcf46xF6tHb3mXvsp9PZiq0ZmVy9VEX8oNcjh9+ac2KAfUhMI4Bt ZqxCnKHzGfUovEoCQLy3Jq2irgWApPKgDK0wfGOapR8HVkilgwS6VSgOg7rgU9xQC0SX prmsfH/GjvWsQNFzWOUFq3QprF+LHoKVTIpDuQAM83wV2TecN1hel3LJRXdQqA+QlKUD mnxA== 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=G9ezp7evjOZKJ358P904p9qdWMlp+LXB67WAKDUGAvU=; b=fd2d21wUtDhfHsyjunFGlzRbTzmWFur4yIbaysecFZSqhYqr7PNwQGzDbx0ae/8y9B aoKD3ahMFr+WLhNrZoevEd1s5lEwq/O9OSphweG4l84nRQ5T5brMudm0XRMm+xYppwin YVe2a/uNjR/TH9lK5SzRK8ec5r+gj7x90wvsROSutOs19tEM0NfnImkXpL448TFTS5iK xvKA6CF6zKXjF5HbeCqJBUXuTZqnUlsa0ScWDQngGG6MLFfR+eflLKQE3oCdL5hIqeJg dIUr44G8mBCea8BY5hWvOolhIZ2hq42sqQD9bdY62p/Y46gheprtL7MfXdrv3kDDZOO6 y2JA== X-Gm-Message-State: AOAM533g3vrqhuDmqMzIJAX4BmNvgjWJFEHfijiOQsr8l1cyKpA3x179 aAw7dVEIgRY/xkDeF8puh6Q= X-Google-Smtp-Source: ABdhPJw9/BU5KlBxePHCFWCqv0cjbOlwA+ftV9Te5GxWWnnwL0HxwFZ/mjos0oxboc7aDxNViUNIbg== X-Received: by 2002:a62:8c93:0:b0:44c:faf:43cd with SMTP id m141-20020a628c93000000b0044c0faf43cdmr20165717pfd.5.1633357359042; Mon, 04 Oct 2021 07:22:39 -0700 (PDT) Received: from kvm.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 8sm13859473pfi.194.2021.10.04.07.22.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 07:22:38 -0700 (PDT) Date: Mon, 4 Oct 2021 14:22:34 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: linux-mm@kvack.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [QUESTION] is SLAB considered legacy and deprecated? Message-ID: <20211004142234.GA3065@kvm.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> <8224ddae-88f5-63ab-c375-473462c50efe@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8224ddae-88f5-63ab-c375-473462c50efe@suse.cz> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 21C17D001BBE X-Stat-Signature: 6htgq6sjsqpc363eh87bzfi1znxt1pyr Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fDVZp6zU; spf=pass (imf20.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1633357359-691224 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 Mon, Oct 04, 2021 at 01:34:17PM +0200, Vlastimil Babka wrote: > On 10/3/21 07:59, Hyeonggon Yoo wrote: > > Hello Vlastimil! I'm happy to discuss with you. > > I hope this discussion to make us think about slab allocator. > > Yeah, it's useful, thanks for asking! > Me too, Thanks for answering. > > On Fri, Oct 01, 2021 at 04:07:56PM +0200, Vlastimil Babka wrote: > >>>> In some contexts it's still being preferred, AFAIK. > >>> > >>> In what context is SLAB or SLUB is preferred? > >> > >> I don't know the full answer. With our distro we have used SLAB, and > >> switched to SLUB after verifying that there are no major regressions. > >> Better debugging features were perhaps the major reason. > >> > > > >>> And what is the core reason that SLUB is used by default? > >> > >> The usual reason in MM, nobody objected :) > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0acd82080768 > >> > > > > What was the decision based on ? performance measurements or anything > > I haven't been around back then, so don't know. Also tried to find this > particular patch (and possible replies) in the linux-mm lore archive, > and didn't succeed. Might have been event sent off-list by mistake. > I can't find it in the list too. Maybe it was not sent to list. > >>>>> So there is a fundamental question coming into my mind: > >>>>> 'is SLAB considered legacy and deprecated?' > >>>> > >>>> To some extend, but not yet in a sense where we would have a deadline to get > >>>> rid of it. > >>>> > >>> What makes you to say 'To some extent'? > >>> That's what I'm curious about :) > > > >> "To some extent" because SLUB is default and if some new stuff was added > >> that only worked with SLUB and not SLAB, there wouldn't be major > >> objections expected. > > > > You said new features are added to only SLUB and there are no > > objections expected, But what makes you to do so? > > > > You are not saying why. what you are saying is just only result. > > What is the mind behind maintaining SLUB and neglecting SLAB? > > David explained it well. I'll add it's a question of motivation, people > generally add features to the subsystem they prefer, and most prefer > SLUB these days, and in that case we don't require the same feature to > be added to SLAB (or even SLOB) as well. But if someone wants to, we > also don't stop them - but to some extent. If someone suddenly came up > with "SLUB has this nice debugging and SLAB not, so I will reimplement > it there" we would be questioning hard if the code churn is really needed. > I got your point. no need to take unnecessary maintenance cost. Thanks, Hyeonggon