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 3FB41C433EF for ; Mon, 4 Oct 2021 01:25:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2151C6121F for ; Mon, 4 Oct 2021 01:25:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232052AbhJDB1V (ORCPT ); Sun, 3 Oct 2021 21:27:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231935AbhJDB1T (ORCPT ); Sun, 3 Oct 2021 21:27:19 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3969C0613EC for ; Sun, 3 Oct 2021 18:25:31 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id rm6-20020a17090b3ec600b0019ece2bdd20so2994781pjb.1 for ; Sun, 03 Oct 2021 18:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=mroagGZ15tDNkaQrtQcB9E+cIqRY9GAKuA9U/CUyqV0=; b=lM/c+5OjZi5Lhe/KYRWElS1YYl9GUQoUs9NulLvb0SIVfStU7egPomPz30W/iAP2Na n6Q4yfFXyw8xR1Y+ieRuYL/3gkG1168fdVceS/78ftEaUj/ENm5Smc5mr22/DAU+iyoE EQAPupCp/quwAEMem5GHXi+MCIhnXXSx69d6QTzWEqVP2QkyuEg8XJOxMclYfx/kmKe9 /wvmc5axacXD1B8jJKGPCoB++0Q2tW31XFr7K2h2l3Ui13s7GEN0+rhn8z83Yb/rbgMC SkO8ZPbxwWiAAOYO9/lIjfHKMWPXQFomt4bEO+nk+FIyaXYa68gQd3sehiQB8/xQLWR1 rIfg== 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:in-reply-to:message-id :references:mime-version; bh=mroagGZ15tDNkaQrtQcB9E+cIqRY9GAKuA9U/CUyqV0=; b=ulpMT1R5sDMfNQERFliXCioth5pn2Ws184pT8O2pJJH85hEVLQ8a0N1Gxz8qO0UHRW zK+kPARh9ElJUR9xXPx+ghADoO7NV8PPVAKiuQlwj0ZVK1Ytw24GNS4JJ4byqHgpytm6 ay/awBfZdwMXRhzX9TEJSpesBU2nVWHwJ2gqA9tXSVYWqJWAwWlEZEz8OiyjqM7Yjp/w +oxbmpFwzpAJt1n85OtDwjBd78xXiGMl8cK1o36JS8Bw/weJDmsw1mYdAetLu6gslhQs VYSs3UTTqBCXONe64CWzRzgDQ3XrjavYjNQjRVnabszy7EFjJUF2FTfcP0W9WBUJaEmG 7OHA== X-Gm-Message-State: AOAM533agfmAjXKSk9AhlgK4V1ZrCGEPzO3w29HABPMAnjdWZ2EJENBL u58rV23TczqayXh7TyP5zuj42A== X-Google-Smtp-Source: ABdhPJwX0TMxB9WjoR2rdxr47tV4Gcqfc0JkH9XfFGmVKGqjwYqnMaz+IUrMRJxWOBPvQb2g1cm4fw== X-Received: by 2002:a17:90a:bd08:: with SMTP id y8mr27196650pjr.123.1633310730863; Sun, 03 Oct 2021 18:25:30 -0700 (PDT) Received: from [2620:15c:17:3:4faa:17e6:3602:9e7d] ([2620:15c:17:3:4faa:17e6:3602:9e7d]) by smtp.gmail.com with ESMTPSA id w185sm9500646pfd.113.2021.10.03.18.25.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Oct 2021 18:25:29 -0700 (PDT) Date: Sun, 3 Oct 2021 18:25:29 -0700 (PDT) From: David Rientjes To: Hyeonggon Yoo <42.hyeyoo@gmail.com> 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? In-Reply-To: <20211003055928.GA7643@linux.asia-northeast3-a.c.our-ratio-313919.internal> Message-ID: <377a622-9a5e-37dc-8f8d-42ae124042b6@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. I would disagree that SLAB isn't currently maintained, I think it's actively maintained. Google actually uses it for its production kernel although we're investigating the performance results that we can obtain from SLUB not that we have per-object memcg accounting. There have been workloads, as you mention, that perform better with SLAB even though SLUB can make up for some of its degradation by throwing more memory at the problem (like per-cpu partial slabs). 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. 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 0FF66C433F5 for ; Mon, 4 Oct 2021 01:25:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F4056121F for ; Mon, 4 Oct 2021 01:25:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9F4056121F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DE00D6B006C; Sun, 3 Oct 2021 21:25:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8F336B0071; Sun, 3 Oct 2021 21:25:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5610900002; Sun, 3 Oct 2021 21:25:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id BA00A6B006C for ; Sun, 3 Oct 2021 21:25:32 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 79136180339AF for ; Mon, 4 Oct 2021 01:25:32 +0000 (UTC) X-FDA: 78657012504.39.D444343 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf15.hostedemail.com (Postfix) with ESMTP id 2F2F7D000979 for ; Mon, 4 Oct 2021 01:25:32 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id rj12-20020a17090b3e8c00b0019f88e44d85so4462371pjb.4 for ; Sun, 03 Oct 2021 18:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=mroagGZ15tDNkaQrtQcB9E+cIqRY9GAKuA9U/CUyqV0=; b=lM/c+5OjZi5Lhe/KYRWElS1YYl9GUQoUs9NulLvb0SIVfStU7egPomPz30W/iAP2Na n6Q4yfFXyw8xR1Y+ieRuYL/3gkG1168fdVceS/78ftEaUj/ENm5Smc5mr22/DAU+iyoE EQAPupCp/quwAEMem5GHXi+MCIhnXXSx69d6QTzWEqVP2QkyuEg8XJOxMclYfx/kmKe9 /wvmc5axacXD1B8jJKGPCoB++0Q2tW31XFr7K2h2l3Ui13s7GEN0+rhn8z83Yb/rbgMC SkO8ZPbxwWiAAOYO9/lIjfHKMWPXQFomt4bEO+nk+FIyaXYa68gQd3sehiQB8/xQLWR1 rIfg== 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:in-reply-to:message-id :references:mime-version; bh=mroagGZ15tDNkaQrtQcB9E+cIqRY9GAKuA9U/CUyqV0=; b=bdq7akWHsXNmbwIYgIClwputLhEONG/RXYH3BwNJmdPoI4PKXebPx9yRZKu5ILAzU8 fSLEDxtosJ6YmUXLm5ibZCd2yAkImCXDrc/l72tgUIlXon/dW0fNUONZ/FNQMtrb1NXw qYPaQPVYVxrEvm8bKNHVY7ID53URQMZk0xd7neQ8xzJ9GPIpgrWkbQEQhmY2a4tTMqiR FzPsrffg8IJIbLWIlpDyZLDwZgg1WXdeV5uDUW5eG/zQbnNwwEE2k0mAuOT4imx5IxqG 8C1G0XqiHHZ+KXpn87hE98JFFanfon+JbwFJEMe0hnAUMnqwOwCKy/+net7etGfS2izO 7j/Q== X-Gm-Message-State: AOAM530uwq8J5/W09kc/6EY91Eg3NKNq+LfUe/OSM10MBIeul+5Q+sN6 MzLUHwZf3yZieuX98XUBHEp6aw== X-Google-Smtp-Source: ABdhPJwX0TMxB9WjoR2rdxr47tV4Gcqfc0JkH9XfFGmVKGqjwYqnMaz+IUrMRJxWOBPvQb2g1cm4fw== X-Received: by 2002:a17:90a:bd08:: with SMTP id y8mr27196650pjr.123.1633310730863; Sun, 03 Oct 2021 18:25:30 -0700 (PDT) Received: from [2620:15c:17:3:4faa:17e6:3602:9e7d] ([2620:15c:17:3:4faa:17e6:3602:9e7d]) by smtp.gmail.com with ESMTPSA id w185sm9500646pfd.113.2021.10.03.18.25.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Oct 2021 18:25:29 -0700 (PDT) Date: Sun, 3 Oct 2021 18:25:29 -0700 (PDT) From: David Rientjes To: Hyeonggon Yoo <42.hyeyoo@gmail.com> 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? In-Reply-To: <20211003055928.GA7643@linux.asia-northeast3-a.c.our-ratio-313919.internal> Message-ID: <377a622-9a5e-37dc-8f8d-42ae124042b6@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2F2F7D000979 X-Stat-Signature: 4cfmrdqz815i5qfdwf8cm5t37pj1amaq Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="lM/c+5Oj"; spf=pass (imf15.hostedemail.com: domain of rientjes@google.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1633310732-517496 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, 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. I would disagree that SLAB isn't currently maintained, I think it's actively maintained. Google actually uses it for its production kernel although we're investigating the performance results that we can obtain from SLUB not that we have per-object memcg accounting. There have been workloads, as you mention, that perform better with SLAB even though SLUB can make up for some of its degradation by throwing more memory at the problem (like per-cpu partial slabs). 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.