linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	richard.weiyang@gmail.com
Subject: Re: [PATCH v2 0/6] Track node vacancy to reduce worst case allocation counts
Date: Tue, 25 Feb 2025 10:40:08 -0500	[thread overview]
Message-ID: <sgohw7e665kdphxgo2gk3yqfhw7qcvh7neei4qwcdec42p6lw6@u2ra53q3346k> (raw)
In-Reply-To: <20250221163610.578409-1-sidhartha.kumar@oracle.com>

* Sidhartha Kumar <sidhartha.kumar@oracle.com> [250221 11:36]:
> v1[1] -> v2:
>   - fix comment for vacant_height which refers to depth per Wei 
> 
>   - add a patch to reorder switch case statements in mas_prealloc_calc and
>     mas_wr_store_entry
> 
>   - use sufficient height in spanning stores
> 
>   - modify patch 2 to use a counter to track ascending the tree rather
>     than overloading mas->depth to have this function.
> 
> ================ overview ========================
> Currently, the maple tree preallocates the worst case number of nodes for
> given store type by taking into account the whole height of the tree. This
> comes from a worst case scenario of every node in the tree being full and
> having to propagate node allocation upwards until we reach the root of the
> tree. This can be optimized if there are vacancies in nodes that are at a
> lower depth than the root node. This series implements tracking the level
> at which there is a vacant node so we only need to allocate until this
> level is reached, rather than always using the full height of the tree.
> The ma_wr_state struct is modified to add a field which keeps track of the
> vacant height and is updated during walks of the tree. This value is then
> read in mas_prealloc_calc() when we decide how many nodes to allocate.
> 
> For rebalancing and spanning stores, we also need to track the lowest
> height at which a node has 1 more entry than the minimum sufficient number
> of entries. This is because rebalancing can cause a parent node to become
> insufficient which results in further node allocations. In this case, we
> need to use the sufficient height as the worst case rather than the vacant
> height.
> 
> patch 1-2: preparatory patches
> patch 3: implement vacant height tracking + update the tests
> patch 4: support vacant height tracking for rebalacning writes
                                              ^^^^^^^^^^^- Typo
> patch 5: implement sufficient height tracking
> patch 6: reorder switch case statements
> 
> ================ results =========================
> Bpftrace was used to profile the allocation path for requesting new maple
> nodes while running stress-ng mmap 120s. The histograms below represent
> requests to kmem_cache_alloc_bulk() and show the count argument. This
> represnts how many maple nodes the caller is requesting in
> kmem_cache_alloc_bulk()
> 
> command: stress-ng --mmap 4 --timeout 120
> 
> mm-unstable 
> 
> @bulk_alloc_req:
> [3, 4)                 4 |                                                    |
> [4, 5)             54170 |@                                                   |
> [5, 6)                 0 |                                                    |
> [6, 7)            893057 |@@@@@@@@@@@@@@@@@@@@                                |
> [7, 8)                 4 |                                                    |
> [8, 9)           2230287 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
> [9, 10)            55811 |@                                                   |
> [10, 11)           77834 |@                                                   |
> [11, 12)               0 |                                                    |
> [12, 13)         1368684 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@                     |
> [13, 14)               0 |                                                    |
> [14, 15)               0 |                                                    |
> [15, 16)          367197 |@@@@@@@@                                            |
> 
> 
> @maple_node_total: 46,630,160
> @total_vmas: 46184591
> 
> mm-unstable + this series
> 
> @bulk_alloc_req:
> [2, 3)               198 |                                                    |
> [3, 4)                 4 |                                                    |
> [4, 5)                43 |                                                    |
> [5, 6)                 0 |                                                    |
> [6, 7)           1069503 |@@@@@@@@@@@@@@@@@@@@@                               |
> [7, 8)                 4 |                                                    |
> [8, 9)           2597268 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
> [9, 10)           472191 |@@@@@@@@@                                           |
> [10, 11)          191904 |@@@                                                 |
> [11, 12)               0 |                                                    |
> [12, 13)          247316 |@@@@                                                |
> [13, 14)               0 |                                                    |
> [14, 15)               0 |                                                    |
> [15, 16)           98769 |@                                                   |
> 
> 
> @maple_node_total: 37,813,856
> @total_vmas: 43493287
> 
> This represents a ~19% reduction in the number of bulk maple nodes allocated.
> 
> For more reproducible results, a historgram of the return value of
> mas_prealloc_calc() is displayed while running the maple_tree_tests
> whcih have a deterministic store pattern
> 
> mas_prealloc_calc() return value mm-unstable
> 1   :  							 (12068)
> 3   :  							 (11836)
> 5   : ***** 						 (271192)
> 7   : ************************************************** (2329329)
> 9   : *********** 					 (534186)
> 10  :  							 (435)
> 11  : *************** 					 (704306)
> 13  : ******** 						 (409781)
> 
> mas_prealloc_calc() return value mm-unstable + this series
> 1   : 							 (12070)
> 3   : ************************************************** (3548777)
> 5   : ********                                           (633458)
> 7   :  							 (65081)
> 9   :  							 (11224)
> 10  :  							 (341)
> 11  :  							 (2973)
> 13  :  							 (68)
> 
> do_mmap latency was also measured for regressions:
> command: stress-ng --mmap 4 --timeout 120
> 
> mm-unstable:
> avg = 7162 nsecs, total: 16101821292 nsecs, count: 2248034
> 
> mm-unstable + this series:
> avg = 6689 nsecs, total: 15135391764 nsecs, count: 2262726
> 
> 
> [1]: https://lore.kernel.org/lkml/20241114170524.64391-1-sidhartha.kumar@oracle.com/T/
> 
> Sidhartha Kumar (6):
>   maple_tree: convert mas_prealloc_calc() to take in a maple write state
>   maple_tree: use height and depth consistently
>   maple_tree: use vacant nodes to reduce worst case allocations
>   maple_tree: break on convergence in mas_spanning_rebalance()
>   maple_tree: add sufficient height
>   maple_tree: reorder mas->store_type case statements
> 
>  include/linux/maple_tree.h       |   4 +
>  lib/maple_tree.c                 | 193 ++++++++++++++++++-------------
>  tools/testing/radix-tree/maple.c | 130 +++++++++++++++++++--
>  3 files changed, 240 insertions(+), 87 deletions(-)
> 
> -- 
> 2.43.0
> 


      parent reply	other threads:[~2025-02-25 15:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-21 16:36 Sidhartha Kumar
2025-02-21 16:36 ` [PATCH v2 1/6] maple_tree: convert mas_prealloc_calc() to take in a maple write state Sidhartha Kumar
2025-02-25 15:40   ` Liam R. Howlett
2025-02-21 16:36 ` [PATCH v2 2/6] maple_tree: use height and depth consistently Sidhartha Kumar
2025-02-25 15:39   ` Liam R. Howlett
2025-02-21 16:36 ` [PATCH v2 3/6] maple_tree: use vacant nodes to reduce worst case allocations Sidhartha Kumar
2025-02-25 15:46   ` Liam R. Howlett
2025-02-25 16:22     ` Sidhartha Kumar
2025-02-26 15:30       ` Liam R. Howlett
2025-02-21 16:36 ` [PATCH v2 4/6] maple_tree: break on convergence in mas_spanning_rebalance() Sidhartha Kumar
2025-02-25 15:47   ` Liam R. Howlett
2025-02-21 16:36 ` [PATCH v2 5/6] maple_tree: add sufficient height Sidhartha Kumar
2025-02-25 16:02   ` Liam R. Howlett
2025-02-25 20:36     ` Sidhartha Kumar
2025-02-26 15:15       ` Liam R. Howlett
2025-02-21 16:36 ` [PATCH v2 6/6] maple_tree: reorder mas->store_type case statements Sidhartha Kumar
2025-02-25 16:03   ` Liam R. Howlett
2025-02-25 15:40 ` Liam R. Howlett [this message]

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=sgohw7e665kdphxgo2gk3yqfhw7qcvh7neei4qwcdec42p6lw6@u2ra53q3346k \
    --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