From: Jakub Kicinski <kuba@kernel.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-mm@kvack.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
John Garry <john.garry@huawei.com>,
linux-block@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC v2 PATCH] mm, sl[au]b: Introduce lockless cache
Date: Thu, 23 Sep 2021 06:28:44 -0700 [thread overview]
Message-ID: <20210923062844.148e08fd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <688e6750-87e9-fb44-ce40-943bad072e48@kernel.dk>
On Wed, 22 Sep 2021 06:58:00 -0600 Jens Axboe wrote:
> > I considered only case 2) when writing code. Well, To support 1),
> > I think there are two ways:
> >
> > a) internally call kmem_cache_free when in_interrupt() is true
> > b) caller must disable interrupt when freeing
> >
> > I think a) is okay, how do you think?
>
> If the API doesn't support freeing from interrupts, then I'd make that
> the rule. Caller should know better if that can happen, and then just
> use kmem_cache_free() if in a problematic context. That avoids polluting
> the fast path with that check. I'd still make it a WARN_ON_ONCE() as
> described and it can get removed later, hopefully.
Shooting from the hip a little but if I'm getting the context right
this is all very similar to the skb cache so lockdep_assert_in_softirq()
may be useful:
/*
* Acceptable for protecting per-CPU resources accessed from BH.
* Much like in_softirq() - semantics are ambiguous, use carefully.
*/
#define lockdep_assert_in_softirq() \
do { \
WARN_ON_ONCE(__lockdep_enabled && \
(!in_softirq() || in_irq() || in_nmi())); \
} while (0)
next prev parent reply other threads:[~2021-09-23 13:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 15:48 [RFC v2 PATCH] mm, sl[au]b: Introduce lockless cache Hyeonggon Yoo
2021-09-20 22:01 ` Matthew Wilcox
2021-09-21 10:56 ` Hyeonggon Yoo
2021-09-21 15:42 ` Hyeonggon Yoo
2021-09-21 16:17 ` Matthew Wilcox
2021-09-22 8:32 ` Hyeonggon Yoo
2021-09-22 9:11 ` Hyeonggon Yoo
2021-09-21 15:37 ` Jens Axboe
2021-09-22 8:19 ` Hyeonggon Yoo
2021-09-22 12:58 ` Jens Axboe
2021-09-23 3:34 ` Hyeonggon Yoo
2021-09-23 13:28 ` Jakub Kicinski [this message]
2021-09-23 3:55 ` Github link here Hyeonggon Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210923062844.148e08fd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
--to=kuba@kernel.org \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.