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 X-Spam-Level: X-Spam-Status: No, score=-1.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D4ECC433F5 for ; Mon, 20 Sep 2021 01:09:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 116EE6104F for ; Mon, 20 Sep 2021 01:09:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 116EE6104F 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 5A9DE900003; Sun, 19 Sep 2021 21:09:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 557F6900002; Sun, 19 Sep 2021 21:09:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41FB9900003; Sun, 19 Sep 2021 21:09:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 2F652900002 for ; Sun, 19 Sep 2021 21:09:45 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D40DF256E4 for ; Mon, 20 Sep 2021 01:09:44 +0000 (UTC) X-FDA: 78606169488.39.2C35835 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf25.hostedemail.com (Postfix) with ESMTP id 979F3B00018E for ; Mon, 20 Sep 2021 01:09:44 +0000 (UTC) Received: by mail-pj1-f53.google.com with SMTP id k23-20020a17090a591700b001976d2db364so11460092pji.2 for ; Sun, 19 Sep 2021 18:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pto4r+NbIB2rnclkYpaJHKBf9z4eQ68+/d/Hn5CuMBM=; b=EDS4Ktlpjn0khBpFQWZa/rcf7pzIIKRv/QRTX3LAYGpLHEy8BWTmL1WUiB+dBDo7kH 6A5zpQrik3Nz5IcjaeL2UT+7MdFTGWC3WDFIfhrz6fhc8Isb8W189/CZEI4QzwIG76ya YDYVx+WP5io3uGzICcpVHnaajVvoblOuH4FifrGsdX2IrfS62v5tBw99nhJZJ19qUw3o d+FZGjJMvW+PmeeyagDA9+FzudvBmiwRlP/TDL2xU4Feu3pjRf1bMHqmmwDWeMyHS6or fQaAvkCi6642D1U84Ert+T6rmhqAQPpN1sHC0X/IL2dMiNPzr4y8k2eMImQCheacRwTU pZ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pto4r+NbIB2rnclkYpaJHKBf9z4eQ68+/d/Hn5CuMBM=; b=sF46BENpm4ClKvFo8C8ZtPEZaJv8gLu1YQ8am6XHWTLOXVm2vIIUY9E2HT4n4W4f9i 8tQzdzjGWqNppo2fADvO3b06seECDmARCK5VS14vWN8dIpQrPcxlLEVImIoL6Uca8k1r SZ3l65YdbBOawpSrtHy+OK+12h0FiUSgLjGsCza76H6/8Qt128K5HsSreLpKpgZlS9Y9 ZdXR3sBbqZpPM3WS5xvRBsGOEdIQYlc3T3lrwiVaTyAghIHOdSYQI0VQa9nJ1Toeju4p 5ih6IY0hlUCFWLZXLKjXfAtf929/QAWlsb3H4be+lEsKIlknCPJpEPlbJHIBDCJDH9qG eE9A== X-Gm-Message-State: AOAM533xa7lgRGbUugb+ueJJunVLm9vM0ybXCQENhq0wqoe1dz6lodaV XzYjLGNvhI+IKK46IZXd7Gk= X-Google-Smtp-Source: ABdhPJwVQA8v1LRupQwomar4+CUInn43EDZhqifgbRroovZmFoQ5wZbLOQFeGGJ5iMJzycSGu4j0jA== X-Received: by 2002:a17:90a:b907:: with SMTP id p7mr26438253pjr.142.1632100183524; Sun, 19 Sep 2021 18:09:43 -0700 (PDT) Received: from kvm.asia-northeast3-a.c.our-ratio-313919.internal (252.229.64.34.bc.googleusercontent.com. [34.64.229.252]) by smtp.gmail.com with ESMTPSA id x19sm12485814pfa.104.2021.09.19.18.09.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Sep 2021 18:09:43 -0700 (PDT) Date: Mon, 20 Sep 2021 01:09:38 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Matthew Wilcox Cc: Christoph Lameter , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jens Axboe Subject: Re: [RFC PATCH] Introducing lockless cache built on top of slab allocator Message-ID: <20210920010938.GA3108@kvm.asia-northeast3-a.c.our-ratio-313919.internal> References: <20210919164239.49905-1-42.hyeyoo@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 979F3B00018E Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=EDS4Ktlp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Stat-Signature: pjx5jyu1cck6kzaiwfoufzyr6pydst9o X-HE-Tag: 1632100184-713467 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: Hello Matthew, Thanks to give me a comment! I appreciate it. On Sun, Sep 19, 2021 at 08:17:44PM +0100, Matthew Wilcox wrote: > On Sun, Sep 19, 2021 at 04:42:39PM +0000, Hyeonggon Yoo wrote: > > It is just simple proof of concept, and not ready for submission yet. > > There can be wrong code (like wrong gfp flags, or wrong error handling, > > etc) it is just simple proof of concept. I want comment from you. > > Have you read: > > https://www.usenix.org/legacy/event/usenix01/full_papers/bonwick/bonwick_html/ > The relevant part of that paper is section 3, magazines. We should have > low and high water marks for number of objects I haven't read that before, but after reading it seems not different from SLAB's percpu queuing. > and we should allocate > from / free to the slab allocator in batches. Slab has bulk alloc/free > APIs already. > There's kmem_cache_alloc_{bulk,free} functions for bulk allocation. But it's designed for large number of allocation to reduce locking cost, not for percpu lockless allocation. Yeah, we can implement lockless cache using kmem_cache_alloc_{bulk, free} but kmem_cache_alloc_{free,bulk} is not enough. > I'd rather see this be part of the slab allocator than a separate API. And I disagree on this. for because most of situation, we cannot allocate without lock, it is special case for IO polling. To make it as part of slab allocator, we need to modify existing data structure. But making it part of slab allocator will be waste of memory because most of them are not using this.