From: Baoquan He <bhe@redhat.com>
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, urezki@gmail.com, shivankg@amd.com,
vishal.moola@gmail.com, linux-kernel@vger.kernel.org,
Baoquan He <bhe@redhat.com>
Subject: [PATCH v2 2/5] mm/vmalloc.c: find the vmap of vmap_nodes in reverse order
Date: Sat, 19 Apr 2025 06:36:50 +0800 [thread overview]
Message-ID: <20250418223653.243436-3-bhe@redhat.com> (raw)
In-Reply-To: <20250418223653.243436-1-bhe@redhat.com>
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>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Shivank Garg <shivankg@amd.com>
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 38d8d8d60985..76ab4d3ce616 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2421,7 +2421,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;
}
@@ -2447,7 +2447,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
next prev parent reply other threads:[~2025-04-18 22:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 22:36 [PATCH v2 0/5] mm/vmalloc.c: code cleanup and improvements Baoquan He
2025-04-18 22:36 ` [PATCH v2 1/5] mm/vmalloc.c: change purge_ndoes as local static variable Baoquan He
2025-04-18 22:36 ` Baoquan He [this message]
2025-04-18 22:36 ` [PATCH v2 3/5] mm/vmalloc.c: optimize code in decay_va_pool_node() a little bit Baoquan He
2025-04-18 22:36 ` [PATCH v2 4/5] mm/vmalloc: optimize function vm_unmap_aliases() Baoquan He
2025-04-18 22:36 ` [PATCH v2 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area() Baoquan He
2025-04-21 4:47 ` Shivank Garg
2025-04-22 8:53 ` [PATCH v2 0/5] mm/vmalloc.c: code cleanup and improvements Uladzislau Rezki
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=20250418223653.243436-3-bhe@redhat.com \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shivankg@amd.com \
--cc=urezki@gmail.com \
--cc=vishal.moola@gmail.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.