From: Uladzislau Rezki <urezki@gmail.com>
To: Dev Jain <dev.jain@arm.com>
Cc: catalin.marinas@arm.com, will@kernel.org, urezki@gmail.com,
akpm@linux-foundation.org, tytso@mit.edu,
adilger.kernel@dilger.ca, cem@kernel.org, ryan.roberts@arm.com,
anshuman.khandual@arm.com, shijie@os.amperecomputing.com,
yang@os.amperecomputing.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
npiggin@gmail.com, willy@infradead.org, david@kernel.org,
ziy@nvidia.com
Subject: Re: [RESEND RFC PATCH 0/2] Enable vmalloc huge mappings by default on arm64
Date: Mon, 12 Jan 2026 11:49:50 +0100 [thread overview]
Message-ID: <aWTRzpqU5yWhlV3u@pc636> (raw)
In-Reply-To: <20251212042701.71993-1-dev.jain@arm.com>
On Fri, Dec 12, 2025 at 09:56:59AM +0530, Dev Jain wrote:
> In the quest for reducing TLB pressure via block mappings, enable huge
> vmalloc by default on arm64 for BBML2-noabort systems which support kernel
> live mapping split.
>
> This series is an RFC, because I cannot get a performance improvement for
> the usual benchmarks which we have. Currently, vmalloc follows an opt-in
> approach for block mappings - the users calling vmalloc_huge() are the ones
> which expect the most advantage from block mappings. Most users of
> vmalloc(), kvmalloc() and kvzalloc() map a single page. After applying this
> series, it is expected that a considerable number of users will produce
> cont mappings, and probably none will produce PMD mappings.
>
> I am asking for help from the community in testing - I believe that one of
> the testing methods is xfstests: a lot of code uses the APIs mentioned
> above. I am hoping that someone can jump in and run at least xfstests, and
> probably some other tests which can take advantage of the reduced TLB
> pressure from vmalloc cont mappings.
>
I checked how often vmalloc/vmap is triggered when i run xfstests. I think
it also depends on env. and can be different from one setup to another.
"echo vmalloc:alloc_vmap_area > set_event"
urezki@milan:~/data/optane/xfs-test/xfstests.git$ wc -l ./vmalloc_traces/*.trace
2875 ./vmalloc_traces/generic_036.trace
30117 ./vmalloc_traces/generic_038.trace
8481 ./vmalloc_traces/generic_051.trace
16986 ./vmalloc_traces/generic_055.trace
6079 ./vmalloc_traces/generic_068.trace
2792 ./vmalloc_traces/generic_070.trace
26945 ./vmalloc_traces/generic_072.trace
2772 ./vmalloc_traces/generic_076.trace
2750 ./vmalloc_traces/generic_083.trace
3319 ./vmalloc_traces/generic_095.trace
2855 ./vmalloc_traces/generic_232.trace
3537 ./vmalloc_traces/generic_269.trace
21265 ./vmalloc_traces/generic_299.trace
3231 ./vmalloc_traces/generic_300.trace
3050 ./vmalloc_traces/generic_323.trace
2831 ./vmalloc_traces/generic_390.trace
4296 ./vmalloc_traces/generic_461.trace
4807 ./vmalloc_traces/generic_476.trace
3198 ./vmalloc_traces/generic_551.trace
3096 ./vmalloc_traces/generic_616.trace
6495 ./vmalloc_traces/generic_627.trace
11232 ./vmalloc_traces/generic_642.trace
11706 ./vmalloc_traces/generic_650.trace
3135 ./vmalloc_traces/generic_750.trace
5926 ./vmalloc_traces/generic_751.trace
77623 ./vmalloc_traces/xfs_013.trace
9172 ./vmalloc_traces/xfs_017.trace
4145 ./vmalloc_traces/xfs_068.trace
2982 ./vmalloc_traces/xfs_104.trace
7293 ./vmalloc_traces/xfs_167.trace
18851 ./vmalloc_traces/xfs_168.trace
4373 ./vmalloc_traces/xfs_442.trace
3550 ./vmalloc_traces/xfs_609.trace
321765 total
urezki@milan:~/data/optane/xfs-test/xfstests.git$
Time execution is different for each test. For example "xfs_013" test
takes around 200 seconds on my system and is in top of number of calls:
77623 / 200 = 388.115 calls/sec
200 / 77623 = 0.002576 = ~each 2.5ms
Please note, i have not checked impact of your patch on time execution
or how TLB pressure is affected.
--
Uladzislau Rezki
prev parent reply other threads:[~2026-01-12 10:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 4:26 [RESEND RFC PATCH 0/2] Enable vmalloc huge mappings by default on arm64 Dev Jain
2025-12-12 4:27 ` [RESEND RFC PATCH 1/2] mm/vmalloc: Do not align size to huge size Dev Jain
2025-12-22 11:47 ` Uladzislau Rezki
2025-12-24 5:05 ` Dev Jain
2025-12-12 4:27 ` [RESEND RFC PATCH 2/2] arm64/mm: Enable huge-vmalloc by default Dev Jain
2026-01-12 10:49 ` Uladzislau Rezki [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=aWTRzpqU5yWhlV3u@pc636 \
--to=urezki@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=cem@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=shijie@os.amperecomputing.com \
--cc=tytso@mit.edu \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yang@os.amperecomputing.com \
--cc=ziy@nvidia.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.