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;
Date:   Sun, 17 Oct 2021 15:39:27 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Christoph Lameter <cl@linux.com>,
        Pekka Enberg <penberg@kernel.org>,
        David Rientjes <rientjes@google.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>
Subject: Re: Do we really need SLOB nowdays?
Message-ID: <YWw1n6y/AGED14HD@casper.infradead.org>
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>
Precedence: bulk

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.