linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>,
	linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org,
	linux-mm@kvack.org, akpm@linux-foundation.org
Subject: Re: [PATCH 3/5] maple_tree: use vacant nodes to reduce worst case allocations
Date: Tue, 19 Nov 2024 09:15:36 -0500	[thread overview]
Message-ID: <i7plirck6zcsk4xguy4yonj2dj7dfdnvvsa2hi6sszfnpgws3o@xpzspa7wrtvq> (raw)
In-Reply-To: <20241119023047.sentd5e75yak36za@master>

* Wei Yang <richard.weiyang@gmail.com> [241118 21:31]:
> On Mon, Nov 18, 2024 at 11:36:18AM -0500, Sidhartha Kumar wrote:
> >On 11/15/24 8:41 PM, Wei Yang wrote:
> >> On Fri, Nov 15, 2024 at 03:34:55PM -0500, Sidhartha Kumar wrote:
> >> > On 11/15/24 2:52 AM, Wei Yang wrote:
...

> >> 
> >> Hmm... I come up with a case in which vacant_height may not high enough.
> >> 
> >> Here is the subtree where spanning write locates. The first level is the
> >> parent node of the second level nodes.
> >> 
> >>                  vacant node
> >>                  +--------+-+-+-------+
> >>                  |        |l|r|       |
> >>                  +--------+-+-+-------+
> >> 
> >>                  l                 r
> >>      +------+    +----+-------+    +---------+--+    +------+
> >>      |      |    |    |       |    |         |  |    |      |
> >>      +------+    +----+-------+    +---------+--+    +------+
> >>                       ^                      ^
> >> 		     |                      |
> >> 		   index                   last
> >> 
> >> When mas_wr_walk_descend() to node l, mas_is_span_wr() return true since last
> >> is in the right sibling, node r. Let's say the parent is vacant and l/r is
> >> leaf. So the request number is (1 * 3) + 1.
> >> 
> >> Let's assume:
> >> 
> >>    * vacant node is just sufficient
> >>    * l's left part + r's right part is sufficient but not overflow
> >> 
> >> Then the "new vacant node" would be deficient and needs another round
> >> rebalance.
> >> 
> >> For this case, I am afraid it doesn't allocate enough nodes. Or I
> >> misunderstand this?
> >
> >I think you are correct and we need to use the sufficient height which is
> >introduced in patch 5 in the spanning store case similar to how patch 5 uses
> >it for the rebalance store case.
> >
> >	case wr_rebalance:
> >		if (wr_mas->sufficient_height < wr_mas->vacant_height) {
> >			ret = (height - wr_mas->sufficient_height)*2 +1;
> >			break;
> >		}
> >		ret = delta * 2 + 1;
> >		break;
> >
> 
> I have thought about this.
> 
> But the spanning write case seems to be a little special to
> splitting/rebalance.
> 
> It could be both require one more extra slot and may need to be rebalanced.
> We are not sure the exact behavior on converge node. Only check one aspect
> seems not enough.
> 
> Do you think so ?

I'm pretty sure the calculation will need to be different than the
rebalance case.  He was just saying that it's going to need to be like
rebalance, but not the same code.

Let's see what Sid comes up with.


  reply	other threads:[~2024-11-19 14:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-14 17:05 [PATCH 0/5] Track node vacancy to reduce worst case allocation counts Sidhartha Kumar
2024-11-14 17:05 ` [PATCH 1/5] maple_tree: convert mas_prealloc_calc() to take in a maple write state Sidhartha Kumar
2024-11-14 17:05 ` [PATCH 2/5] maple_tree: use height and depth consistently Sidhartha Kumar
2024-11-14 17:05 ` [PATCH 3/5] maple_tree: use vacant nodes to reduce worst case allocations Sidhartha Kumar
2024-11-15  7:52   ` Wei Yang
2024-11-15 20:34     ` Sidhartha Kumar
2024-11-16  1:41       ` Wei Yang
2024-11-18 16:36         ` Sidhartha Kumar
2024-11-19  2:30           ` Wei Yang
2024-11-19 14:15             ` Liam R. Howlett [this message]
2024-11-14 17:05 ` [PATCH 4/5] maple_tree: break on convergence in mas_spanning_rebalance() Sidhartha Kumar
2024-11-15  7:14   ` Wei Yang
2024-11-14 17:05 ` [PATCH 5/5] maple_tree: add sufficient height Sidhartha Kumar
2024-11-14 21:39 ` [PATCH 0/5] Track node vacancy to reduce worst case allocation counts Sid Kumar
2024-11-19  9:59   ` Wei Yang
2024-11-26 19:32     ` Sidhartha Kumar

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=i7plirck6zcsk4xguy4yonj2dj7dfdnvvsa2hi6sszfnpgws3o@xpzspa7wrtvq \
    --to=liam.howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maple-tree@lists.infradead.org \
    --cc=richard.weiyang@gmail.com \
    --cc=sidhartha.kumar@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox