From: Jung-JaeJoon <[email protected]>
If there are not enough nodes, mas_node_count() set an error state via mas_set_err()
and return control flow to the beginning.
In the return flow, mas_nomem() checks the error status, allocates new nodes,
and resumes execution again.
In particular,
if this happens in mas_split() in the slow_path section executed in mas_wr_modify(),
unnecessary work is repeated, causing a slowdown in speed as below flow:
_begin:
mas_wr_modify() --> if (new_end >= mt_slots[wr_mas->type]) --> goto slow_path
slow_path:
--> mas_wr_bnode() --> mas_store_b_node() --> mas_commit_b_node() --> mas_split()
--> mas_node_count() return to _begin
But, in the above flow, if mas_node_count() is executed before entering slow_path,
execution efficiency is improved by allocating nodes without entering slow_path repeatedly.
Signed-off-by: JaeJoon Jung <[email protected]>
---
lib/maple_tree.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 2d7d27e6ae3c..8ffabd73619f 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -4176,8 +4176,13 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas)
* path.
*/
new_end = mas_wr_new_end(wr_mas);
- if (new_end >= mt_slots[wr_mas->type])
+ if (new_end >= mt_slots[wr_mas->type]) {
+ mas->depth = mas_mt_height(mas);
+ mas_node_count(mas, 1 + mas->depth * 2);
+ if (mas_is_err(mas))
+ return;
goto slow_path;
+ }
/* Attempt to append */
if (mas_wr_append(wr_mas, new_end))
--
2.17.1
Hello, Liam.
Thank you very much for the detailed answer and explanation.
I tested this patch in userspace.
In user space, this phenomenon always occurs when kmem_cache_alloc()
is executed to allocate a new node.
I will try to test it in more detail in kernel space.
I will also refer to the notes from the email list you shared
and send results once a more clear analysis has been made.
Thanks,
JaeJoon Jung
On Sun, 2 Jun 2024 at 11:41, Liam R. Howlett <[email protected]> wrote:
>
> * Jung-JaeJoon <[email protected]> [240531 22:55]:
> > From: Jung-JaeJoon <[email protected]>
> >
> > If there are not enough nodes, mas_node_count() set an error state via mas_set_err()
> > and return control flow to the beginning.
> >
> > In the return flow, mas_nomem() checks the error status, allocates new nodes,
> > and resumes execution again.
> >
> > In particular,
> > if this happens in mas_split() in the slow_path section executed in mas_wr_modify(),
> > unnecessary work is repeated, causing a slowdown in speed as below flow:
> >
> > _begin:
> > mas_wr_modify() --> if (new_end >= mt_slots[wr_mas->type]) --> goto slow_path
> > slow_path:
> > --> mas_wr_bnode() --> mas_store_b_node() --> mas_commit_b_node() --> mas_split()
> > --> mas_node_count() return to _begin
> >
> > But, in the above flow, if mas_node_count() is executed before entering slow_path,
> > execution efficiency is improved by allocating nodes without entering slow_path repeatedly.
>
> Thank you for your patch, but I have to NACK this change.
>
> You are trying to optimise the work done when we are out of memory,
> which is a very rare state. How did you check this works?
>
> If we run out of memory, the code will kick back to mas_nomem() and
> may start running in reclaim to free enough memory for the allocations.
> There is nothing we can do to make a meaningful change in the speed of
> execution at this point. IOW, the duplicate work is the least of our
> problems.
>
> This change has also separated the allocations from why we are
> allocating - which isn't really apparent in this change. We could put
> in a comment about why we are doing this, but the difference in
> execution speed when we are in a low memory, probably reclaim retry
> situation is not worth this complication.
>
> We also have a feature on the mailing list called "Store type" around
> changing how this works to make preallocations avoid duplicate work and
> it is actively being worked on (as noted in the email to the list). [1]
> The key difference being that the store type feature will allow us to
> avoid unnecessary work that happens all the time for preallocations.
>
> [1] http://lists.infradead.org/pipermail/maple-tree/2023-December/003098.html
>
> Thanks,
> Liam
>
> >
> > Signed-off-by: JaeJoon Jung <[email protected]>
> > ---
> > lib/maple_tree.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> > index 2d7d27e6ae3c..8ffabd73619f 100644
> > --- a/lib/maple_tree.c
> > +++ b/lib/maple_tree.c
> > @@ -4176,8 +4176,13 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas)
> > * path.
> > */
> > new_end = mas_wr_new_end(wr_mas);
> > - if (new_end >= mt_slots[wr_mas->type])
> > + if (new_end >= mt_slots[wr_mas->type]) {
> > + mas->depth = mas_mt_height(mas);
> > + mas_node_count(mas, 1 + mas->depth * 2);
> > + if (mas_is_err(mas))
> > + return;
> > goto slow_path;
> > + }
> >
> > /* Attempt to append */
> > if (mas_wr_append(wr_mas, new_end))
> > --
> > 2.17.1
> >