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 DB9DDC433F5 for ; Sun, 17 Oct 2021 14:40:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F2B9361040 for ; Sun, 17 Oct 2021 14:40:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F2B9361040 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 41DD3900002; Sun, 17 Oct 2021 10:40:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CCCF6B0072; Sun, 17 Oct 2021 10:40:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BC1D900002; Sun, 17 Oct 2021 10:40:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0144.hostedemail.com [216.40.44.144]) by kanga.kvack.org (Postfix) with ESMTP id 1BA4F6B006C for ; Sun, 17 Oct 2021 10:40:07 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C23E71827059D for ; Sun, 17 Oct 2021 14:40:06 +0000 (UTC) X-FDA: 78706189212.06.05A46B1 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 7AF6F1908 for ; Sun, 17 Oct 2021 14:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=80/t/c+UlQL/GFdmduRihZ3yN36jPN478cR6XUY8+rc=; b=EQf/D1wHYBCM3t9+mrYTWvCfzX rI3KoP/nNTFqiMfBT3ddBel9BWMSfC5E3yBXi1brZgOmnxOKvjeCVywhNP79wnQPA6DTIwrj1kQqp IicM1zc1+igaX1EfXsA5lF6YNBzCtcZb4JvwPqkrjMiDoyGFn8X182ZXfVoTn4vx62lmWsurJM//o 4use1qlTTP8kK5fO+xnNNgYzs0bAoLN2a672XHjSzdF/aY+M0WU6LqbKmamlwGviQI+E5vLirNwmU EzH0Lh//jwGcFWchb7lgqENAftHA+weR0vullrovJcuH4ZpPH9wzlC/Ed63weY8l8ravGMKswcYN7 RDSd1NKA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mc7Jv-00ALY5-4T; Sun, 17 Oct 2021 14:39:34 +0000 Date: Sun, 17 Oct 2021 15:39:27 +0100 From: Matthew Wilcox To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka Subject: Re: Do we really need SLOB nowdays? Message-ID: References: <20211017042852.GA3050@kvm.asia-northeast3-a.c.our-ratio-313919.internal> <20211017133618.GA7989@kvm.asia-northeast3-a.c.our-ratio-313919.internal> <20211017135708.GA8442@kvm.asia-northeast3-a.c.our-ratio-313919.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211017135708.GA8442@kvm.asia-northeast3-a.c.our-ratio-313919.internal> X-Stat-Signature: tyz3tgxcud56ifx1yjjux7e3cso8eeas Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="EQf/D1wH"; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7AF6F1908 X-HE-Tag: 1634481605-43191 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 17, 2021 at 01:57:08PM +0000, Hyeonggon Yoo wrote: > On Sun, Oct 17, 2021 at 01:36:18PM +0000, Hyeonggon Yoo wrote: > > On Sun, Oct 17, 2021 at 04:28:52AM +0000, Hyeonggon Yoo wrote: > > > I've been reading SLUB/SLOB code for a while. SLUB recently became > > > real time compatible by reducing its locking area. > > > > > > for now, SLUB is the only slab allocator for PREEMPT_RT because > > > it works better than SLAB on RT and SLOB uses non-deterministic method, > > > sequential fit. > > > > > > But memory usage of SLUB is too high for systems with low memory. > > > So In my local repository I made SLOB to use segregated free list > > > method, which is more more deterministic, to provide bounded latency. > > > > > > This can be done by managing list of partial pages globally > > > for every power of two sizes (8, 16, 32, ..., PAGE_SIZE) per NUMA nodes. > > > minimal allocation size is size of pointers to keep pointer of next free object > > > like SLUB. > > > > > > By making objects in same page to have same size, there's no > > > need to iterate free blocks in a page. (Also iterating pages isn't needed) > > > > > > Some cleanups and more tests (especially with NUMA/RT configs) needed, > > > but want to hear your opinion about the idea. Did not test on RT yet. > > > > > > Below is result of benchmarks and memory usage. (on !RT) > > > with 13% increase in memory usage, it's nine times faster and > > > bounded fragmentation, and importantly provides predictable execution time. > > > > > > > Hello linux-mm, I improved it and it uses lower memory > > and 9x~13x faster than original SLOB. it shows much less fragmentation > > after hackbench. > > > > Rather than managing global freelist that has power of 2 sizes, > > I made a kmem_cache to manage its own freelist (for each NUMA nodes) and > > Added support for slab merging. So It quite looks like a lightweight SLUB now. > > > > I'll send rfc patch after some testing and code cleaning. > > > > I think it is more RT-friendly becuase it's uses more deterministic > > algorithm (But lock is still shared among cpus). Any opinions for RT? > > Hi there. after some thinking, I got a new question: > If a lightweight SLUB is better than SLOB, > Do we really need SLOB nowdays? Better for what use case? SLOB is for machines with 1-16MB of RAM.