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 E1F11C433EF for ; Mon, 4 Oct 2021 14:56:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6FA8261029 for ; Mon, 4 Oct 2021 14:56:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6FA8261029 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gentwo.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E6D9D940055; Mon, 4 Oct 2021 10:56:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1E2594000B; Mon, 4 Oct 2021 10:56:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0CB6940055; Mon, 4 Oct 2021 10:56:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id BE44F94000B for ; Mon, 4 Oct 2021 10:56:39 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7366B299C5 for ; Mon, 4 Oct 2021 14:56:39 +0000 (UTC) X-FDA: 78659056518.22.C89E70B Received: from gentwo.de (vmi485042.contaboserver.net [161.97.139.209]) by imf06.hostedemail.com (Postfix) with ESMTP id A2F65801C348 for ; Mon, 4 Oct 2021 14:56:38 +0000 (UTC) Received: by gentwo.de (Postfix, from userid 1001) id E033CB00424; Mon, 4 Oct 2021 16:56:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id DD8A4B00261; Mon, 4 Oct 2021 16:56:36 +0200 (CEST) Date: Mon, 4 Oct 2021 16:56:36 +0200 (CEST) From: Christoph Lameter To: Hyeonggon Yoo <42.hyeyoo@gmail.com> cc: Vlastimil Babka , linux-mm@kvack.org, Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: Queueing is outside of SLUB nowdays In-Reply-To: <20211001003908.GA2657@linux.asia-northeast3-a.c.our-ratio-313919.internal> Message-ID: References: <20210927090347.GA2533@linux.asia-northeast3-a.c.our-ratio-313919.internal> <8aa15f4b-71de-5283-5ebc-d8d1a323473d@suse.cz> <20211001003908.GA2657@linux.asia-northeast3-a.c.our-ratio-313919.internal> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A2F65801C348 X-Stat-Signature: 4hxr6qppm71pmxh3gfy7kyahwazz7m95 Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de X-HE-Tag: 1633359398-350685 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 Fri, 1 Oct 2021, Hyeonggon Yoo wrote: > 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.) The queuing within in SLUB/SLAB is lockless. > So current approach on place where slab's performance is critical > is implementing queuing layer on top of slab. If you have to use object specific characteristics to optimize then yes you can optimize further. However, the slab allocators implement each their own form of queuing that is generic. > Then new question arising: > - Is that proper way to solve fundamental problem? There is a problem? > - why not use SLAB if they need queuing? SLAB is LIFO queuing whereas SLUB uses spatial considerations and queues within a page before going outside. Slab requires disabling interrupts, SLUB is optimized to rely on per cpu atomics and there are numerous other differences. > - how does this approach work on SLAB? SLAB has a lockless layer that is only requiring disabling interrupts. It provides a generic queuing layer as well. See my talk on Slab allocators awhile back. https://www.youtube.com/watch?v=h0VMLXavx30