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 1B9D1C433F5 for ; Sat, 19 Feb 2022 11:59:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E73A6B0071; Sat, 19 Feb 2022 06:59:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 397096B0072; Sat, 19 Feb 2022 06:59:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 238786B0074; Sat, 19 Feb 2022 06:59:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 1200D6B0071 for ; Sat, 19 Feb 2022 06:59:48 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C166C96F21 for ; Sat, 19 Feb 2022 11:59:47 +0000 (UTC) X-FDA: 79159385214.12.6FD1FC8 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf13.hostedemail.com (Postfix) with ESMTP id 66C1B20007 for ; Sat, 19 Feb 2022 11:59:47 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id c4so4530168pfl.7 for ; Sat, 19 Feb 2022 03:59:47 -0800 (PST) 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=Q3S/BU0h5z1TWDtM7/trwzzdXaxUs1NRowNdwGsTgok=; b=YuK+xUE3N2UL4vhozvRT2RTu3henp67FsQdQcK59s4ZCoRpw/EAhgehnyf0YsqzR4W BT1m3M2DQzlt8rP7rULMnrJZxz2ivFGTXOZ6gTQCisFOde+YRONXi5n7Jac+Oeqc9Hx0 vfLnTOosOgoL5hMLh+LGaOHxWIcAnV6kwxLe7Q4U9kQ/z+hPNYOvi8YO8cp/SUpuQAk0 L3odT2JVMpt6ZQd1ZspgGSjwUAjPHoDpXxFqQLy5JgCFRV+aicxqVORXKqOxEwIoq3IA /e9eD2Z4ZfX0bhzZE/koRo8quqzM52m7YDNHAtLMVBVU6uoPItrQPyXEaApF+Kz5DbEx MG8Q== 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=Q3S/BU0h5z1TWDtM7/trwzzdXaxUs1NRowNdwGsTgok=; b=nbEkYrBG9vwprop8xM3hw0fVZcGCPY5x3uYgav0363PxJpaXHik/ZXQbusgRLWfPBn oj6l7S4YEepumPp5XdMX32+EjC8jKY3NqP3IbbLDYzlNkPd47lpfrPGN3En4h06X1QWX DLGpOeL+FYFjnNjjiyt8OFHWzsn/uhOQuDVzhdIlEylwMbGNmi+Cm/Nu7F+kJeCQOdiw UZAzb6CmigHLWp8IiB53lWzbgzNDZ2Xpgw/jQwezy7GeQnDeejpC9nfjy6GiBfIC2fme 36LE3DKOOpFrTDU+NmzWWPf6QZzzLzVUdoRak41JBvsAv55HsQdvkOmGWoVafjQpdzH7 R5Kw== X-Gm-Message-State: AOAM531LWb2HM5YlTtM/78gvLRDaK6zua14EJPNXuAbirCa/SE4kKESO QVriHxmoyhn6Q+SvCk5NXg4= X-Google-Smtp-Source: ABdhPJydTEJwQNWaSddpo4lHXPhWP5QjSCtR4+XvQy6/uJEiNdd4sa1yXcoDRDgWMI3nVuAk+c4zJA== X-Received: by 2002:a05:6a00:24ca:b0:4e1:cb76:32da with SMTP id d10-20020a056a0024ca00b004e1cb7632damr10876785pfv.81.1645271986371; Sat, 19 Feb 2022 03:59:46 -0800 (PST) Received: from ip-172-31-19-208.ap-northeast-1.compute.internal (ec2-18-181-137-102.ap-northeast-1.compute.amazonaws.com. [18.181.137.102]) by smtp.gmail.com with ESMTPSA id k16sm13009844pgh.45.2022.02.19.03.59.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Feb 2022 03:59:45 -0800 (PST) Date: Sat, 19 Feb 2022 11:59:41 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: David Laight Cc: Vlastimil Babka , Christoph Lameter , Matthew Wilcox , Christoph Lameter , Linux Memory Management List , LKML , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton Subject: Re: Do we really need SLOB nowdays? Message-ID: References: <20211028100414.GA2928@kvm.asia-northeast3-a.c.our-ratio-313919.internal> <20211210110835.GA632811@odroid> <20211215062904.GA1150813@odroid> <54c6fff8-8c79-463b-a359-96e37bd13674@suse.cz> <7829ee15074448d5a7cec1a0e3c352d4@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7829ee15074448d5a7cec1a0e3c352d4@AcuMS.aculab.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 66C1B20007 X-Stat-Signature: ej6xthhaczyyttsssast9ygptztpeepw Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YuK+xUE3; spf=pass (imf13.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1645271987-20738 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 Fri, Feb 18, 2022 at 04:10:28PM +0000, David Laight wrote: > From: Hyeonggon Yoo > > Sent: 18 February 2022 10:13 > ... > > I think SLUB can be memory-efficient as SLOB. > > Is SLOB (Address-Ordered next^Wfirst fit) stronger to fragmentation than SLUB? > > Dunno, but I had to patch the vxworks malloc to use 'best fit' > because 'first fit' based on a fifo free list was really horrid. > > I can't imagine an address ordered 'first fit' really being that much better. > > There are probably a lot more allocs and frees than the kernel used to have. > > Also isn't the performance of a 'first fit' going to get horrid > when there are a lot of small items on the free list. SLOB is focused on low memory usage, at the cost of poor performance. Its speed is not a concern. I think Address-Ordered sequential fit method pretty well in terms of low memory usage. And I think SLUB may replace SLOB, but we need to sure SLUB is absolute winner.. I wonder How slab maintainers think? > > Does SLUB split pages into 3s and 5s (on cache lime boundaries) > as well as powers of 2? > SLUB/SLAB use different strategy than SLOB, for better allocation performance. It's variant of segregated storage method. SLUB/SLAB both creates dedicated "caches" for each type of object. for example, on my system, there are slab cache for dentry(192), filp(256), fs_cache(64) ... etc. Objects that has different types are by default managed by different cache, which holds manages of pages. slab caches can be merged for better cacheline utilization. SLUB/SLAB also creates global kmalloc caches at boot time for power of 2 objects and (128, 256, 512, 1K, 2K, 4K, 8K on my system). Thanks, Hyeonggon. > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >