From: Brian Foster <bfoster@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
ikent@redhat.com, onestero@redhat.com
Subject: Re: [PATCH 1/3] radix-tree: propagate all tags in idr tree
Date: Wed, 15 Jun 2022 10:43:33 -0400 [thread overview]
Message-ID: <YqnwFZxmiekL5ZOC@bfoster> (raw)
In-Reply-To: <YqnhW2CI1kbJ3NqR@casper.infradead.org>
On Wed, Jun 15, 2022 at 02:40:43PM +0100, Matthew Wilcox wrote:
> On Wed, Jun 15, 2022 at 08:57:56AM -0400, Brian Foster wrote:
> > On Wed, Jun 15, 2022 at 04:12:14AM -0700, Christoph Hellwig wrote:
> > > On Tue, Jun 14, 2022 at 02:09:47PM -0400, Brian Foster wrote:
> > > > The IDR tree has hardcoded tag propagation logic to handle the
> > > > internal IDR_FREE tag and ignore all others. Fix up the hardcoded
> > > > logic to support additional tags.
> > > >
> > > > This is specifically to support a new internal IDR_TGID radix tree
> > > > tag used to improve search efficiency of pids with associated
> > > > PIDTYPE_TGID tasks within a pid namespace.
> > >
> > > Wouldn't it make sense to switch over to an xarray here rather
> > > then adding new features to the radix tree?
> > >
> >
> > The xarray question crossed my mind when I first waded into this code
> > and realized the idr tree seems to be some sort of offshoot or custom
> > mode of the core radix tree. I eventually realized that the problem wrt
> > to normal radix tree tags in the idr variant was that the tag
> > propagation logic in the idr variant simply didn't care to handle
> > traditional tags, presumably because they were unused in that mode. So
> > this patch doesn't really add a feature to the radix-tree, it just fixes
> > up some of the grotty idr tree logic to handle both forms of tags.
> >
> > I assume it makes sense for this to move towards xarray in general, but
> > I don't have enough context on either side to know what the sticking
> > points are. In particular, does xarray support something analogous to
> > IDR_FREE or otherwise solve whatever problem idr currently depends on it
> > for (i.e. efficient id allocation)? I think Willy has done work in this
> > area so I'm hoping he can chime in on some of that if he's put any
> > thought into the idr thing specifically..
>
> Without going into the history of the idr/radix-tree/xarray, the
> current hope is that we'll move all users of the idr & radix tree
> over to the xarray API. It's fundamentally the same data structure
> for all three now, just a question of the API change.
>
> The XArray does indeed have a way to solve the IDR_FREE problem;
> you need to declare an allocating XArray:
> https://www.kernel.org/doc/html/latest/core-api/xarray.html#allocating-xarrays
>
> and using XA_MARK_1 and XA_MARK_2 should work the way you want them to.
>
Interesting, thanks. I'll have to dig more into this to grok the current
state of the radix-tree interface vs. the underlying data structure. If
I follow correctly, you're saying the radix-tree api is essentially
already a translation layer to the xarray these days, and we just need
to move legacy users off the radix-tree api so we can eventually kill it
off...
Brian
next prev parent reply other threads:[~2022-06-15 14:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 18:09 [PATCH 0/3] proc: improve root readdir latency with many threads Brian Foster
2022-06-14 18:09 ` [PATCH 1/3] radix-tree: propagate all tags in idr tree Brian Foster
2022-06-15 11:12 ` Christoph Hellwig
2022-06-15 12:57 ` Brian Foster
2022-06-15 13:40 ` Matthew Wilcox
2022-06-15 14:43 ` Brian Foster [this message]
2022-06-15 16:34 ` Matthew Wilcox
2022-06-28 12:55 ` Christian Brauner
2022-06-28 14:53 ` Brian Foster
2022-06-29 19:13 ` Brian Foster
2022-07-11 20:24 ` Matthew Wilcox
2022-06-15 13:33 ` Ian Kent
2022-06-14 18:09 ` [PATCH 2/3] pid: use idr tag to hint pids associated with group leader tasks Brian Foster
2022-06-14 18:09 ` [PATCH 3/3] proc: use idr tgid tag hint to iterate pids in readdir Brian Foster
2022-06-15 13:44 ` Matthew Wilcox
2022-06-15 14:44 ` Brian Foster
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=YqnwFZxmiekL5ZOC@bfoster \
--to=bfoster@redhat.com \
--cc=hch@infradead.org \
--cc=ikent@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=onestero@redhat.com \
--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.