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 026B9C433F5 for ; Mon, 18 Oct 2021 09:45:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 803666108E for ; Mon, 18 Oct 2021 09:45:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 803666108E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D6D666B006C; Mon, 18 Oct 2021 05:45:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1CEC6B0071; Mon, 18 Oct 2021 05:45:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0BDF6B0072; Mon, 18 Oct 2021 05:45:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id B33036B006C for ; Mon, 18 Oct 2021 05:45:53 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 72B501802E8C4 for ; Mon, 18 Oct 2021 09:45:53 +0000 (UTC) X-FDA: 78709076586.18.371CAD8 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf04.hostedemail.com (Postfix) with ESMTP id 3622250000B3 for ; Mon, 18 Oct 2021 09:45:51 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id t7so1116940pgl.9 for ; Mon, 18 Oct 2021 02:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9wShPcm04yQjRDx6oZyaTuEEqvFrwO8qa7VeZemOTHQ=; b=T4C8uPE88RB9SbE9UMTzJcBjUQsUP0KsytZaTpS8SfLDpxaM2bKXeABwCVqah79yja U8O4HrMapymCauNJK42vyiX8EZ8x4u/7erWDQ9Oz7nv9Rncrg2AYXiMk86LIO38Lk5sg fKrFTcI/eRGqJW1pZOpTuB0phMQPVntwSassluZzogWcZIHiH/WM3q2ITOjVyQs0FG9h mKAQNC89xlODuotmu35lvExp7p47fu+fXpdjJnYa6df+irP3ikqYGhZPH05hedMx7qxA hJuCDxnhRQ7/8KN3rwDCcT6UE9ily/KyEYFKb5V9hHx0G303uBhaCWGd3cq4LIaQqqD6 BFEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9wShPcm04yQjRDx6oZyaTuEEqvFrwO8qa7VeZemOTHQ=; b=ogsEatFbqqigU9xqBVv7E5Hn4X+04IBMmq1Z5TqAH3zAGp6B5bCmilCP5TUA5QxDUW JT/SYQSI7hYH0A9EsUcCOd7F9lvqK0nxqryG+bnWG8tn6Il/Is2maaLj1LsCkratGySe cePP+81/Gf7BokTIiWryPIN0KKbV473BZ4hsO2MAFMar8pWpY40ksQyZZuHG+IP4bFAv HHwKxuTT4OU3mgWFNw3138aX1B9NrATdSaKnCkx4HmF0kp3jud/lDfUHyLsr5F8EjwxN +zUMkR+cJXGKBonEtfVLx4QGG3101tUwC+rdW3kZ2ETF2SLb/7fOlwbMs8RtuPyvr1Ql Dkrg== X-Gm-Message-State: AOAM5330a5PULlYHQp53qxRYtwgTTU6XUM0CAZVeAasIsoa8nHaR6TYZ iIttOF28PhG/EJCACziEqMvMkZEli3HchPE/biE= X-Google-Smtp-Source: ABdhPJxB805njtKfjLW6Nusag2bSTmCX56r1LqrQv0p3ykNn0C5lh3nHI0ZHcuviejFp0dtOTlY860uCt7JlVj5F/gM= X-Received: by 2002:a63:b007:: with SMTP id h7mr22360596pgf.443.1634550352211; Mon, 18 Oct 2021 02:45:52 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Mon, 18 Oct 2021 18:45:41 +0900 Message-ID: Subject: Re: Do we really need SLOB nowdays? To: Matthew Wilcox Cc: Linux Memory Management List , LKML , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka Content-Type: multipart/alternative; boundary="0000000000001c714105ce9d694c" X-Stat-Signature: e6j33semb7banou5rkfwd43x5fqzfar9 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=T4C8uPE8; spf=pass (imf04.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3622250000B3 X-HE-Tag: 1634550351-527312 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: --0000000000001c714105ce9d694c Content-Type: text/plain; charset="UTF-8" On Sun, Oct 17, 2021, 11:40 PM Matthew Wilcox 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! > --0000000000001c714105ce9d694c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 recen= tly became
> > > real time compatible by reducing its locking area.
> > >
> > > for now, SLUB is the only slab allocator for PREEMPT_RT beca= use
> > > it works better than SLAB on RT and SLOB uses non-determinis= tic method,
> > > sequential fit.
> > >
> > > But memory usage of SLUB is too high for systems with low me= mory.
> > > 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<= br> > > > 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 config= s) needed,
> > > but want to hear your opinion about the idea. Did not test o= n RT yet.
> > >
> > > Below is result of benchmarks and memory usage. (on !RT)
> > > with 13% increase in memory usage, it's nine times faste= r 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 fragment= ation
> > 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 nod= es) and
> > Added support for slab merging. So It quite looks like a lightwei= ght 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 determi= nistic
> > 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?=C2=A0 SLOB is for machines with 1-16MB of RAM.

1~1= 6M is smaller than I thought. Hmm... I'm going to see how it works on t= iny configuration. Thank you Matthew!
--0000000000001c714105ce9d694c--