Re: Do we really need SLOB nowdays?

[Hyeonggon Yoo <42.hyeyoo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]

On Sun, Oct 17, 2021, 11:40 PM Matthew Wilcox <willy@infradead.org> wrote:

> 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.
>

1~16M is smaller than I thought. Hmm... I'm going to see how it works on
tiny configuration. Thank you Matthew!

>

[-- Attachment #2: Type: text/html, Size: 3626 bytes --]