Message-ID: <20230712152738.ld7rn5zmmhtc6wkg@revolver>
Date:   Wed, 12 Jul 2023 11:27:38 -0400
From:   "Liam R. Howlett" <Liam.Howlett@...cle.com>
To:     Peng Zhang <zhangpeng.00@...edance.com>
Cc:     maple-tree@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: Maple Tree Work

Dropping Danilo from the Cc..

I was asked to add linux-mm to the list, so I did that as well.

If anyone else is interested in seeing the full list, it's on lkml [1] and
the maple-tree list [2].

Thank you Peng for looking at the list and taking time to think about
the items.

* Peng Zhang <zhangpeng.00@...edance.com> [230712 07:49]:
> 
> 
> 在 2023/7/8 00:38, Liam R. Howlett 写道:
> >   - Fork & Dup tree + Delete DONT_COPY
> >   	This is to optimize dup_mmap() in kernel/fork.c, but other
> > 	users may want faster duplications of a tree.
> > 	This should be faster than building a tree in bulk mode.  The
> > 	idea is to just copy each node and replace the pointers in,
> > 	probably, a BFS order.  Once the leaves are reached, the VMAs
> > 	will be replaced by the copies made in fork, unless DONT_COPY is
> > 	set, in which case the VMA will be deleted from the copied tree.
> > 	DONT_COPY is not common and since the tree isn't visible, all
> > 	nodes should be available for reuse (no RCU worries).
> If DONT_COPY is set, this method will be complicated, because the gaps
> adjacent to it need to be merged, and the gaps of all ancestor nodes need to
> be updated.

My understanding is that this is a rare event; there aren't many VMAs
marked this way.  The store operation already does all the necessary
work for deleting an entry. The gap tracking is also updated, and that
would only happen if the new gap is larger.  Are you concerned about the
performance/runtime of handling the DONT_COPY in this way?

> 
> I have another idea to build a tree, if inserted in order, we only
> insert at the leaf node. All leaf nodes are connected using a linked
> list. In the end we get a linked list with only leaf nodes. Then we
> construct non-leaf nodes layer by layer from bottom to top. I think
> this is also faster than bulk mode. Another advantage of this method
> is that we are applicable to more scenarios, do not need the original
> tree, only need to know the ranges inserted in order. I don't know
> how fast this method is, so we can discuss it.

What is the advantage of a linked list over just building the tree as
you go?  Considering the non-leaf nodes are just a list of nodes
already, and you will have to do the same work of setting pivots,
allocating nodes, and filling them after you have the linked list.

What work do you avoid that would make a linked list faster than bulk
insert or a tree copy/replace VMAs?  I was thinking that we could avoid
a lot of the work involved with splitting/pushing and the parent
construction by using memcpy of each node, replace each slot (and
parent) with a new memcpy of the mirrored tree, then have a minimum
amount of modifications to delete the DONT_COPY during the VMA
replacement.  BFS copy would ensure we wouldn't modify the source tree
during VMA replacement and deletion (DONT_COPY).  So the rebalancing (in
bulk insert), pivot calculations, metadata, and gaps are (mostly) saved
by using memcpy.

>From what I understand from your linked list idea, we would need to
construct the child node by examining each entry and know that a certain
entry is a DONT_COPY (ie: VMA logic would be needed in the maple tree
code or a callback?). We really can't have VMA logic in the maple tree
code, so we could do some sort of loop through the VMAs to add the entry
to the list if desired.

Once we have a linked list, we still need to figure out each pivot for
the parent (I guess we won't use the last slot so there is a pivot to
check?), and each max gap in each child to construct the upper layers
of the tree.  Is this correct?

I guess we would still need to adjust the last node to ensure sufficient
entries as well, so as we add items we may need to rebalance the last
leaf with the second-last leaf.

The bulk store currently adjusts the split to favour splitting
left, could you get the same result by strictly filling the nodes?  This
would have to have special handling to rebalance the last one - which we
have a pretty good idea of when it's going to happen as we have a count
(and the DONT_COPY is rare).

Are you thinking you could compact the tree at the same time to gain
efficiency?

What would you consider a sufficient packed tree?  It's best to keep
some space around for expansion/contraction.  This works out since, I
think, we would need to keep that last slot free so we have a pivot to
check in your linked list plan. Initial development with strict
split/join rules resulted in a 'jittering' of nodes as the number of
entries in a node shifted just above/below the threshold so we relaxed
the merging of nodes to avoid such a scenario.

Let me know if you would like me to put your name beside the Fork & Dup
Tree item in the list of work.

[1] https://lore.kernel.org/lkml/20230707163815.ns4kdz7iut5octjv@revolver/
[2] https://lists.infradead.org/mailman/listinfo/maple-tree

Thanks,
Liam

Powered by blists - more mailing lists