All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Roberts <ryan.roberts@arm.com>
To: Yang Shi <yang@os.amperecomputing.com>,
	will@kernel.org, catalin.marinas@arm.com,
	akpm@linux-foundation.org, Miko.Lenczewski@arm.com,
	dev.jain@arm.com, scott@os.amperecomputing.com, cl@gentwo.org
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] arm64: mm: support large block mapping when rodata=full
Date: Wed, 6 Aug 2025 08:20:09 +0100	[thread overview]
Message-ID: <b2d3e684-e3dc-41b5-9708-ca5926c55ebf@arm.com> (raw)
In-Reply-To: <e65ed11d-68ef-4b9c-80ad-7e880743b3d3@os.amperecomputing.com>

On 05/08/2025 19:53, Yang Shi wrote:

[...]

>>> +    arch_enter_lazy_mmu_mode();
>>> +    ret = split_pgd(pgd_offset_k(start), start, end);
>> My instinct still remains that it would be better not to iterate over the range
>> here, but instead call a "split(start); split(end);" since we just want to split
>> the start and end. So the code would be simpler and probably more performant if
>> we get rid of all the iteration.
> 
> It should be more performant for splitting large range, especially the range
> includes leaf mappings at different levels. But I had some optimization to skip
> leaf mappings in this version, so it should be close to your implementation from
> performance perspective. And it just walks the page table once instead of twice.
> It should be more efficient for small split, for example, 4K.

I guess this is the crux of our disagreement. I think the "walks the table once
for 4K" is a micro optimization, which I doubt we would see on any benchmark
results. In the absence of data, I'd prefer the simpler, smaller, easier to
understand version.

Both implementations are on list now; perhaps the maintainers can steer us.

Thanks,
Ryan


  reply	other threads:[~2025-08-06  7:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-24 22:11 [v5 PATCH 0/4] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full Yang Shi
2025-07-24 22:11 ` [PATCH 1/4] arm64: Enable permission change on arm64 kernel block mappings Yang Shi
2025-07-24 22:11 ` [PATCH 2/4] arm64: cpufeature: add AmpereOne to BBML2 allow list Yang Shi
2025-08-01 14:36   ` Ryan Roberts
2025-08-04 23:20   ` Christoph Lameter (Ampere)
2025-07-24 22:11 ` [PATCH 3/4] arm64: mm: support large block mapping when rodata=full Yang Shi
2025-07-29 12:34   ` Dev Jain
2025-08-05 21:28     ` Yang Shi
2025-08-06  0:10       ` Yang Shi
2025-08-01 14:35   ` Ryan Roberts
2025-08-04 10:07     ` Ryan Roberts
2025-08-05 18:53     ` Yang Shi
2025-08-06  7:20       ` Ryan Roberts [this message]
2025-08-07  0:44         ` Yang Shi
2025-07-24 22:11 ` [PATCH 4/4] arm64: mm: split linear mapping if BBML2 is not supported on secondary CPUs Yang Shi
2025-07-26 11:10   ` kernel test robot
2025-08-01 16:14   ` Ryan Roberts
2025-08-05 18:59     ` Yang Shi
2025-08-05  7:54   ` Ryan Roberts
2025-08-05 17:45     ` Yang Shi
  -- strict thread matches above, loose matches on Subject: below --
2025-05-31  2:41 [v4 PATCH 0/4] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full Yang Shi
2025-05-31  2:41 ` [PATCH 3/4] arm64: mm: support " Yang Shi
2025-06-16 11:58   ` Ryan Roberts
2025-06-16 12:33     ` Ryan Roberts
2025-06-17 21:01       ` Yang Shi
2025-06-16 16:24   ` Ryan Roberts
2025-06-17 21:09     ` Yang Shi
2025-06-23 13:26       ` Ryan Roberts
2025-06-23 19:12         ` Yang Shi
2025-06-26 22:39         ` Yang Shi
2025-07-23 17:38         ` Dev Jain
2025-07-23 20:51           ` Yang Shi
2025-07-24 11:43             ` Dev Jain
2025-07-24 17:59               ` Yang Shi

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=b2d3e684-e3dc-41b5-9708-ca5926c55ebf@arm.com \
    --to=ryan.roberts@arm.com \
    --cc=Miko.Lenczewski@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=cl@gentwo.org \
    --cc=dev.jain@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scott@os.amperecomputing.com \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.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.