All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yin, Fengwei" <fengwei.yin@intel.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: <maple-tree@lists.infradead.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>,
	"Liu, Yujie" <yujie.liu@intel.com>
Subject: Re: [PATCH 00/14] Reduce preallocations for maple tree
Date: Fri, 2 Jun 2023 16:10:40 +0800	[thread overview]
Message-ID: <7a5dc9ce-b58f-e1b3-db1a-d00a8a556ae5@intel.com> (raw)
In-Reply-To: <20230601021605.2823123-1-Liam.Howlett@oracle.com>

Hi Liam,

On 6/1/2023 10:15 AM, Liam R. Howlett wrote:
> Initial work on preallocations showed no regression in performance
> during testing, but recently some users (both on [1] and off [android]
> list) have reported that preallocating the worst-case number of nodes
> has caused some slow down.  This patch set addresses the number of
> allocations in a few ways.
> 
> During munmap() most munmap() operations will remove a single VMA, so
> leverage the fact that the maple tree can place a single pointer at
> range 0 - 0 without allocating.  This is done by changing the index in
> the 'sidetree'.
> 
> Re-introduce the entry argument to mas_preallocate() so that a more
> intelligent guess of the node count can be made.
> 
> Patches are in the following order:
> 0001-0002: Testing framework for benchmarking some operations
> 0003-0004: Reduction of maple node allocation in sidetree
> 0005:      Small cleanup of do_vmi_align_munmap()
> 0006-0013: mas_preallocate() calculation change
> 0014:      Change the vma iterator order
I did run The AIM:page_test on an IceLake 48C/96T + 192G RAM platform with
this patchset.

The result has a little bit improvement:
Base (next-20230602):
  503880
Base with this patchset:
  519501

But they are far from the none-regression result (commit 7be1c1a3c7b1):
  718080


Some other information I collected:
With Base, the mas_alloc_nodes are always hit with request: 7.
With this patchset, the request are 1 or 5.

I suppose this is the reason for improvement from 503880 to 519501.

With commit 7be1c1a3c7b1, mas_store_gfp() in do_brk_flags never triggered
mas_alloc_nodes() call. Thanks.


Regards
Yin, Fengwei

> 
> [1] https://lore.kernel.org/linux-mm/202305061457.ac15990c-yujie.liu@intel.com/
> 
> Liam R. Howlett (14):
>   maple_tree: Add benchmarking for mas_for_each
>   maple_tree: Add benchmarking for mas_prev()
>   mm: Move unmap_vmas() declaration to internal header
>   mm: Change do_vmi_align_munmap() side tree index
>   mm: Remove prev check from do_vmi_align_munmap()
>   maple_tree: Introduce __mas_set_range()
>   mm: Remove re-walk from mmap_region()
>   maple_tree: Re-introduce entry to mas_preallocate() arguments
>   mm: Use vma_iter_clear_gfp() in nommu
>   mm: Set up vma iterator for vma_iter_prealloc() calls
>   maple_tree: Move mas_wr_end_piv() below mas_wr_extend_null()
>   maple_tree: Update mas_preallocate() testing
>   maple_tree: Refine mas_preallocate() node calculations
>   mm/mmap: Change vma iteration order in do_vmi_align_munmap()
> 
>  fs/exec.c                        |   1 +
>  include/linux/maple_tree.h       |  23 ++++-
>  include/linux/mm.h               |   4 -
>  lib/maple_tree.c                 |  78 ++++++++++----
>  lib/test_maple_tree.c            |  74 +++++++++++++
>  mm/internal.h                    |  40 ++++++--
>  mm/memory.c                      |  16 ++-
>  mm/mmap.c                        | 171 ++++++++++++++++---------------
>  mm/nommu.c                       |  45 ++++----
>  tools/testing/radix-tree/maple.c |  59 ++++++-----
>  10 files changed, 331 insertions(+), 180 deletions(-)
> 

  parent reply	other threads:[~2023-06-02  8:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01  2:15 [PATCH 00/14] Reduce preallocations for maple tree Liam R. Howlett
2023-06-01  2:15 ` [PATCH 01/14] maple_tree: Add benchmarking for mas_for_each Liam R. Howlett
2023-06-01  2:15 ` [PATCH 02/14] maple_tree: Add benchmarking for mas_prev() Liam R. Howlett
2023-06-01  2:15 ` [PATCH 03/14] mm: Move unmap_vmas() declaration to internal header Liam R. Howlett
2023-06-01  2:15 ` [PATCH 04/14] mm: Change do_vmi_align_munmap() side tree index Liam R. Howlett
2023-06-01  2:15 ` [PATCH 05/14] mm: Remove prev check from do_vmi_align_munmap() Liam R. Howlett
2023-06-01  2:15 ` [PATCH 06/14] maple_tree: Introduce __mas_set_range() Liam R. Howlett
2023-06-01  2:15 ` [PATCH 07/14] mm: Remove re-walk from mmap_region() Liam R. Howlett
2023-06-01  2:15 ` [PATCH 08/14] maple_tree: Re-introduce entry to mas_preallocate() arguments Liam R. Howlett
2023-06-01  2:16 ` [PATCH 09/14] mm: Use vma_iter_clear_gfp() in nommu Liam R. Howlett
2023-06-01  2:16 ` [PATCH 10/14] mm: Set up vma iterator for vma_iter_prealloc() calls Liam R. Howlett
2023-06-01  2:16 ` [PATCH 11/14] maple_tree: Move mas_wr_end_piv() below mas_wr_extend_null() Liam R. Howlett
2023-06-01  2:16 ` [PATCH 12/14] maple_tree: Update mas_preallocate() testing Liam R. Howlett
2023-06-01  2:16 ` [PATCH 13/14] maple_tree: Refine mas_preallocate() node calculations Liam R. Howlett
2023-06-02 10:37   ` Peng Zhang
2023-06-02 18:53     ` Liam R. Howlett
2023-06-01  2:16 ` [PATCH 14/14] mm/mmap: Change vma iteration order in do_vmi_align_munmap() Liam R. Howlett
2023-06-02  8:10 ` Yin, Fengwei [this message]
2023-06-02 18:55   ` [PATCH 00/14] Reduce preallocations for maple tree Liam R. Howlett
2023-06-04 12:10     ` Yin, Fengwei
2023-06-05  3:28   ` Peng Zhang
2023-06-05  4:41     ` Yin Fengwei
2023-06-05  6:18       ` Yin, Fengwei
2023-06-05  7:59         ` Peng Zhang
2023-06-05 14:03           ` Liam R. Howlett
2023-06-05 14:27             ` Peng Zhang
2023-06-05 14:44               ` Liam R. Howlett
2023-06-05 15:06                 ` Peng Zhang
2023-06-06  1:34             ` Yin Fengwei
2023-06-06  2:41             ` Hugh Dickins
2023-06-06  2:55               ` Yin, Fengwei
2023-06-06  3:08                 ` Hugh Dickins
2023-06-06  3:11                   ` Yin, Fengwei
2023-06-06 16:07                     ` Liam R. Howlett

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=7a5dc9ce-b58f-e1b3-db1a-d00a8a556ae5@intel.com \
    --to=fengwei.yin@intel.com \
    --cc=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=yujie.liu@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.