Re: Maple Tree for next

[Stephen Rothwell <sfr@canb.auug.org.au>]

[-- Attachment #1: Type: text/plain, Size: 3512 bytes --]

Hi Liam,

On Thu, 17 Feb 2022 02:07:47 +0000 Liam Howlett <liam.howlett@oracle.com> wrote:
>
> * Matthew Wilcox <willy@infradead.org> [220216 16:21]:
> > On Thu, Feb 17, 2022 at 08:04:26AM +1100, Stephen Rothwell wrote:  
> > > 
> > > On Wed, 16 Feb 2022 19:14:53 +0000 Liam Howlett <liam.howlett@oracle.com> 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 for all that.

Added from today (though depending on the complexity of conflicts
against Matthew's folio tree and Andrew's quilt series, I may have to
drop it again).

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]