Re: Maple Tree for next

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Matthew Wilcox <willy@xxxxxxxxxxxxx> [220216 16:21]:
> On Thu, Feb 17, 2022 at 08:04:26AM +1100, Stephen Rothwell wrote:
> > Hi Liam,
> > 
> > On Wed, 16 Feb 2022 19:14:53 +0000 Liam Howlett <liam.howlett@xxxxxxxxxx> wrote:
> > >
> > > Please include a new tree in linux-next:
> > > 
> > > https://github.com/oracle/linux-uek/tree/mainline/maple
> > > Aka
> > > https://github.com/oracle/linux-uek.git mainline/maple
> > 
> > That does no exist :-(
> 
> Transposition; the correct URL is:
> 
> https://github.com/oracle/linux-uek.git maple/mainline

Thanks Matthew.
Sorry about the URL mix up.

> 
> > Please tell me something about you (I can't find you in the MAINTAINERS
> > file) and this tree i.e. what it will contain, its path to Linus' tree
> > (direct or via another tree).
> 
> I'll let Liam answer these questions himself :-)

I'm a developer at Oracle in the Linux Kernel team.  Matthew Wilcox and
I designed the maple tree and I wrote most of implementation and the VMA
changes, Matthew wrote the VMA iterator and any other parts that I
didn't.  I've added myself to the MAINTAINERS file for the maple tree
and associated files (test and doc) in the tree.

This git tree is to deliver the Maple Tree data structure along with the
necessary changes to track VMAs using the maple tree.  The maple tree is
a B-tree variant that's RCU-safe for non-overlapping ranges.   Using the
maple tree gets us to an RCU-safe data structure which is a big step
towards less mmap_lock contention.  This git tree drops the vmacache &
double linked list from VMA tracking and introduces a cleaner VMA
iterator from Matthew.  If you would like to know more about the maple
tree, it has been presented at OSSNA 2019, LCA 2019 by Matthew and at
LPC2019 and LPC2021 by myself, it was also the subject of an LWN article
in Feb 2021.  The tree has many uses beyond VMA tracking, but this is
the hardest problem we could find.

The path upstream is direct.  In addition to sending the patches out for
review to the mm list, I've been discussing these patches with a number
of developers across different organizations in the mm area on a regular
basis and the general consensus is the direct path is best taken for
a change like this.

Thanks,
Liam




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux