From: Uladzislau Rezki <urezki@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, urezki@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] mm/vmalloc.c: find the vmap of vmap_nodes in reverse order
Date: Tue, 15 Apr 2025 17:25:39 +0200 [thread overview]
Message-ID: <Z_56cxJLgnfYK9yY@pc636> (raw)
In-Reply-To: <20250415023952.27850-3-bhe@redhat.com>
On Tue, Apr 15, 2025 at 10:39:49AM +0800, Baoquan He wrote:
> When finding VA in vn->busy, if VA spans several zones and the passed
> addr is not the same as va->va_start, we should scan the vn in reverse
> odrdr because the starting address of VA must be smaller than the passed
> addr if it really resides in the VA.
>
> E.g on a system nr_vmap_nodes=100,
>
> <----va---->
> -|-----|-----|-----|-----|-----|-----|-----|-----|-----|-
> ... n-1 n n+1 n+2 ... 100 0 1
>
> VA resides in node 'n' whereas it spans 'n', 'n+1' and 'n+2'. If passed
> addr is within 'n+2', we should try nodes backwards on 'n+1' and 'n',
> then succeed very soon.
>
> Meanwhile we still need loop around because VA could spans node from 'n'
> to node 100, node 0, node 1.
>
> Anyway, changing to find in reverse order can improve efficiency on
> many CPUs system.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
> mm/vmalloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index aca1905d3397..488d69b56765 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2436,7 +2436,7 @@ struct vmap_area *find_vmap_area(unsigned long addr)
>
> if (va)
> return va;
> - } while ((i = (i + 1) % nr_vmap_nodes) != j);
> + } while ((i = (i + nr_vmap_nodes - 1) % nr_vmap_nodes) != j);
>
> return NULL;
> }
> @@ -2462,7 +2462,7 @@ static struct vmap_area *find_unlink_vmap_area(unsigned long addr)
>
> if (va)
> return va;
> - } while ((i = (i + 1) % nr_vmap_nodes) != j);
> + } while ((i = (i + nr_vmap_nodes - 1) % nr_vmap_nodes) != j);
>
> return NULL;
> }
> --
> 2.41.0
>
It depends. Consider a below situation:
addr
|
VA V
<------------>
<---|---|---|---|---|---|---|--->
0 1 2 3 0 1 2 3
basically it matters how big VA and how many nodes it spans. But i
agree that an assumption to reverse back is more convinced in most
cases.
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
next prev parent reply other threads:[~2025-04-15 15:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 2:39 [PATCH 0/5] mm/vmalloc.c: code cleanup and improvements Baoquan He
2025-04-15 2:39 ` [PATCH 1/5] mm/vmalloc.c: change purge_ndoes as local static variable Baoquan He
2025-04-15 10:47 ` Uladzislau Rezki
2025-04-15 19:08 ` Shivank Garg
2025-04-15 23:53 ` Vishal Moola (Oracle)
2025-04-15 2:39 ` [PATCH 2/5] mm/vmalloc.c: find the vmap of vmap_nodes in reverse order Baoquan He
2025-04-15 15:25 ` Uladzislau Rezki [this message]
2025-04-15 23:41 ` Baoquan He
2025-04-15 19:09 ` Shivank Garg
2025-04-15 2:39 ` [PATCH 3/5] mm/vmalloc.c: optimize code in decay_va_pool_node() a little bit Baoquan He
2025-04-15 10:29 ` Shivank Garg
2025-04-15 14:05 ` Baoquan He
2025-04-15 19:02 ` Shivank Garg
2025-04-16 13:50 ` Uladzislau Rezki
2025-04-17 2:51 ` Baoquan He
2025-04-17 16:18 ` Uladzislau Rezki
2025-04-15 2:39 ` [PATCH 4/5] mm/vmalloc: optimize function vm_unmap_aliases() Baoquan He
2025-04-15 10:44 ` Uladzislau Rezki
2025-04-15 19:10 ` Shivank Garg
2025-04-15 23:54 ` Vishal Moola (Oracle)
2025-04-15 2:39 ` [PATCH 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area() Baoquan He
2025-04-15 6:44 ` Baoquan He
2025-04-15 7:22 ` Shivank Garg
2025-04-15 13:01 ` Baoquan He
2025-04-15 19:00 ` Shivank Garg
2025-04-15 22:57 ` Baoquan He
2025-04-16 14:28 ` Uladzislau Rezki
2025-04-17 3:02 ` Baoquan He
2025-04-17 16:17 ` Uladzislau Rezki
2025-04-15 15:29 ` [PATCH 0/5] mm/vmalloc.c: code cleanup and improvements Uladzislau Rezki
2025-04-15 22:55 ` Baoquan He
2025-04-15 19:06 ` Shivank Garg
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=Z_56cxJLgnfYK9yY@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.