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.7 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 3BDD5C433EF for ; Mon, 20 Sep 2021 15:55:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC23161159 for ; Mon, 20 Sep 2021 15:55:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DC23161159 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 82D196B0072; Mon, 20 Sep 2021 11:55:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B608900002; Mon, 20 Sep 2021 11:55:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67D6D6B0074; Mon, 20 Sep 2021 11:55:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0094.hostedemail.com [216.40.44.94]) by kanga.kvack.org (Postfix) with ESMTP id 5832E6B0072 for ; Mon, 20 Sep 2021 11:55:25 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 00D0282499A8 for ; Mon, 20 Sep 2021 15:55:25 +0000 (UTC) X-FDA: 78608401410.18.2CAFF43 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf17.hostedemail.com (Postfix) with ESMTP id 950A0F00039F for ; Mon, 20 Sep 2021 15:55:24 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id m21so8594191pgu.13 for ; Mon, 20 Sep 2021 08:55:24 -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=ypt/RRITG4KeHBKpsPFjVXvxZMnO9UA0tX+4neKhUYk=; b=cHKUZm01QvVJRxXVV0vcJwU6DZ/MTRk5nd0viSm00OhVyIQb9DA/qdfBHBxwzzWaYB L+qFOWw/O4BaRLGCTouZ/8t8HfcFw3KaegxM0X/nwZF7Pqnw7eXwtsOEOURfipfKncn6 gMkTKWUwpa4NWfM+j8OUCQawKwI0PfrEkzqxrnE4LEvf0MRk+WdW5bNS7ESnYUZZ6K+i ZyTNFmgaU+dMWM6rWZTtIo/BbGp+jTZGs/absYSAfK3uPRwZttddMe649+AYVVqiY9xe hnyPB3tHmdY165xb3hGQ70+JemxRTop04YWCK4KX6xSfpWNSVmQdZCA1TWoIUhdUAeBk /2EQ== 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=ypt/RRITG4KeHBKpsPFjVXvxZMnO9UA0tX+4neKhUYk=; b=6qaKSq3X5z9LxR5j56CKHXEkySgt05JB1j7/x2AG6QyUvePf/6OAxrD0KOtsDt1Uez ydUcPSR1Q9LbrO2BPP7vNSGlzojQw6GiRa0c7EMMtC7OhHC3mlogsqEhcQNcTPtz9Byr 2ZyKY727faBtDo0aO/fITCGDIJ+g7QtwbNKmr1++J+QGmPE2udxQN3uq5UGVmFhaMoVx Gm/2Nrt2Sj43djdQ4b0LEbWphgYUowld44XnraBwWRk8imYeUCogKAfwTOQto1tWgFAi vLK28FJLYz/zdI26nk/zCsj+GP1rhDxJgqbrdYOFWe77jIZZ/LRaf2sdDhRjbR59WxaL 3sBg== X-Gm-Message-State: AOAM532PjG90sCwl3kSD86ht9ZIPtm61Wlxv00kdERaM1eEVo2TnoKA4 b4W0aX35rLlD1ys+sapyAQk= X-Google-Smtp-Source: ABdhPJwrFb5fwvBnS2V1qYm6wmBmNdmeuOIP+kS0q8gOtH0/J260495VhNHYtPBCFKMmF8I0EC/IAg== X-Received: by 2002:a63:ea58:: with SMTP id l24mr24254590pgk.334.1632153323650; Mon, 20 Sep 2021 08:55:23 -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 v7sm13687153pjk.37.2021.09.20.08.55.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Sep 2021 08:55:23 -0700 (PDT) Date: Mon, 20 Sep 2021 15:55:18 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: Matthew Wilcox , Christoph Lameter , David Rientjes , Joonsoo Kim , Andrew Morton , 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: <20210920155518.GB31923@kvm.asia-northeast3-a.c.our-ratio-313919.internal> References: <20210919164239.49905-1-42.hyeyoo@gmail.com> <20210920010938.GA3108@kvm.asia-northeast3-a.c.our-ratio-313919.internal> <432da236-4d8c-1013-cd57-42c352281862@suse.cz> <20210920115536.GA3117@kvm.asia-northeast3-a.c.our-ratio-313919.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 950A0F00039F X-Stat-Signature: 9x67fi9m6786w4yxixw7phaorus8dcrs Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cHKUZm01; spf=pass (imf17.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1632153324-229594 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 Mon, Sep 20, 2021 at 02:02:19PM +0200, Vlastimil Babka wrote: > On 9/20/21 13:55, Hyeonggon Yoo wrote: > > On Mon, Sep 20, 2021 at 11:07:36AM +0200, Vlastimil Babka wrote: > >> I guess making it opt-in only for caches where performance improvement was > >> measured would make it easier to add, as for some caches it would mean no > >> improvement, but increased memory usage. But of course it makes the API more > >> harder to use. > > > > Do you mean "lockless cache" it should be separate from slab because some caches > > doesn't benefit at all? > > I meant it seems to be a valid approach to have a special kmem_cache flag > and allocation function variants, as you discussed. That covers the "some > caches don't benefit at all" while being an integral part of the allocator, > so others don't have to build ad-hoc solutions on top of it, and possibly it > can be also more optimized given access to the SLUB internals. Okay! I sent RFC v2. please check if how does look like to you: https://lore.kernel.org/linux-mm/20210920154816.31832-1-42.hyeyoo@gmail.com/T/#u > >> I'd be careful about the name "lockless", as that's ambiguous. Is it "mostly > >> lockless" therefore fast, but if the cache is empty, it will still take > >> locks as part of refill? > > > > It is actually "mostly lockless" so it is ambiguous. > > Can you suggest a name? like try_lockless or anything? > > "cached" instead of "lockless" ? > added kmem_cache_alloc_cached, kmem_cache_free_cached in v2. Thanks for your opinion Vlastimil, Hyeonggon. > >> Or is it lockless always, therefore useful in > >> contexts that can take no locks, but then the caller has to have fallbacks > >> in case the cache is empty and nothing is allocated? > >> > >> [1] https://lore.kernel.org/linux-mm/20100804024531.914852850@linux.com/T/#u > >