lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 1 Oct 2021 00:39:08 +0000
From:   Hyeonggon Yoo <42.hyeyoo@...il.com>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     linux-mm@...ck.org, Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Queueing is outside of SLUB nowdays

On Mon, Sep 27, 2021 at 07:03:19PM +0200, Vlastimil Babka wrote:
> On 9/27/21 11:03, Hyeonggon Yoo wrote:
> > Hello there,
> > 
> > I've been working on adding 'lockless cache' on sl[au]b for a while.
> > But what it actually does is actually adding 'queuing' on slub.
> 
> Yeah, I pointed out those threads from 2011 that called it exactly that...
> was there any conclusion why that was not ultimately merged?

Looking at other layers, they implemented queuing layer outside of SLUB.
See commit 795bb1c00dd ("net: bulk free infrastructure for NAPI context,
use napi_consume_skb") for example. They made skb cache because SLUB is
not suitable for intensive alloc/free.

And because the queue is outside of slab, it can go lockless
depending on it's context. (But it's not easy to do so in slab because
slab is general purpose allocator.)

So current approach on place where slab's performance is critical
is implementing queuing layer on top of slab.

Then new question arising:
    - Is that proper way to solve fundamental problem?
      - why not use SLAB if they need queuing?
      - how does this approach work on SLAB?

    - If there are no problems with queuing outside of slab, why does
      SLAB exist? can we just drop SLAB?

I think we need to think about questions above.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ