Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp3537612pxb; Mon, 4 Oct 2021 04:36:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRqcGRDjAaj0CsqpsBoxWrv8M5UWjGzFjjxkYaj5TVEqvViSDuxN6v2NQk5rJYs8Z99qfs X-Received: by 2002:a17:90a:1991:: with SMTP id 17mr36503827pji.149.1633347411297; Mon, 04 Oct 2021 04:36:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633347411; cv=none; d=google.com; s=arc-20160816; b=x5NCBdEafUq2KSYg9mcj/oRWZHnVhYESo5aad4E63Hw+d8SAUABRav/thiV12DJ0/4 K6bXTShxo0m5nbmaT+VASatJhlKTkKigfw7/mKw4FgtST9VkaIkDSBhtxoBGPJBciSsL KZWPCd1SrUY5OAQ9j5HVCH43cLdlxtw3wi7C/pYe88RUUNqSjgd+3YwhW3PACwugKqgY RboudtF21Rq9ypEFgULmg2kOsGb2a4fh0lG603dWx4eu3YRNpMCkFmh57P/cezP8XoJQ Cxk3hM+kNcJLuUmB+W6oagQKgdF+JSbYRy2AdjR5UH0NqVRDc3oDdNZKYZe+XH6C2ucp ecMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=jCIcbz578d05l8H6orwYONZYlALfoCLI+RMgU0tteQM=; b=Fp3+SJD7W607xVFN2D4+Ari0I3eBiUgjr8IJNhHVdqxvgdmScd7RBfz+qfgI8F2O57 2CKneMaAjl6xRqiOSrbEDebbatjjkf4h9IE2U7ASfRzh8ui4OEc76HzPGwCd/5ACQ/Ig BGYjk7+j+UpjR8p8gqsVzeBfgOTaASZGNvOb9tAVz09Y99UB4JayQzZ+pF1tNeQ2pvsl GzSJ87/UIVMg6X+9IcjHo1mrlH23fkR7pNFDXTzRmiMBikjKkCNe+OGyFvWi57eYn6KV xsc23hSjXNW4th83sdTOIycHS9iZo461KkNNLEt7kl0QwuZcXyDWaaeBe3doE3q2rgX5 CVKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=jwtkeGlJ; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x184si14381223pgd.479.2021.10.04.04.36.38; Mon, 04 Oct 2021 04:36:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=jwtkeGlJ; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232426AbhJDLgJ (ORCPT + 99 others); Mon, 4 Oct 2021 07:36:09 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:40682 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232193AbhJDLgI (ORCPT ); Mon, 4 Oct 2021 07:36:08 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 73048222D2; Mon, 4 Oct 2021 11:34:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1633347258; h=from:from:reply-to: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; bh=jCIcbz578d05l8H6orwYONZYlALfoCLI+RMgU0tteQM=; b=jwtkeGlJbe1185EhljyGhHf4T7eG8yv0WGhGRTiLIX/EOarfB1kMltTmzeLaTU1UbTN97Y v/n4/plRBRGfrPs4Raw9n1GgRCkP6bkWFvafNl2f/gWuSZJjIiWf8N5HQNHNfr0k9nrE7m bAxDqHoeLgNnbHa50tTvQRQGBY53tQw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1633347258; h=from:from:reply-to: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; bh=jCIcbz578d05l8H6orwYONZYlALfoCLI+RMgU0tteQM=; b=c7mE1xQhR4T8/hpz9RbCTXOZ+oEvqfmGPvX+uxCO2JaYeYNbcaXLG3CiUINn8cuyHL5zUW tMF0Kq/FRjpVjzCg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A63101348D; Mon, 4 Oct 2021 11:33:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Q7f7J6DmWmEsBAAAMHmgww (envelope-from ); Mon, 04 Oct 2021 11:33:52 +0000 Message-ID: <8224ddae-88f5-63ab-c375-473462c50efe@suse.cz> Date: Mon, 4 Oct 2021 13:34:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0.3 Subject: Re: [QUESTION] is SLAB considered legacy and deprecated? Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm@kvack.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-kernel@vger.kernel.org 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> From: Vlastimil Babka In-Reply-To: <20211003055928.GA7643@linux.asia-northeast3-a.c.our-ratio-313919.internal> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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! > 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. > else? 'Because nobody objected' is not a good reason to make a decision. :) >>>>> 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.