From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>, artem.kuzin@huawei.com
Cc: catalin.marinas@arm.com, akpm@linux-foundation.org,
vbabka@kernel.org, cl@gentwo.org, linux@armlinux.org.uk,
will@kernel.org, mark.rutland@arm.com, liam@infradead.org,
rppt@kernel.org, surenb@google.com, mhocko@suse.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, wangkefeng.wang@huawei.com,
panov.nikita@huawei.com
Subject: Re: [RFC PATCH 00/18] mm: arm64: Add kernel replication feature
Date: Thu, 27 Aug 2026 21:04:48 +0200 [thread overview]
Message-ID: <bbd45126-8d43-40eb-8a69-a7fb6d2378f1@kernel.org> (raw)
In-Reply-To: <apBqjq24aG_s2ZTM@gremlin>
[...]
About to go on PTO, some random points :)
>
>> [12] - Optimize this_cpu_*() ops for non-x86 (ARM64 for this series)
>>
>> As of today, none of it was merged into mainline.
>
> I mean :) maybe take that as a hint? If a number of series trying to do X get
> rejected by upstream, that is maybe suggestive of barking up the wrong tree?
I'd have expected an explanation at that point why previous approaches were not
merged and how this patch set is sufficiently different that it is worth
maintainer's time.
>
>> However, after thorough re-evaluation, we were not able to observe
>> performance improvement for the x86 platform, so we have decided to stop this
>> direction and switch on arm64.
>
> I mean, why? You should provide details here, this is quite hand-wavey. You are
> also proposing core mm changes for something that seems specific to unique
> hardware as far as I can tell, which is a big ask.
What I consider interesting is "after thorough re-evaluation, we were not able
to observe performance improvement for the x86 platform".
How confident are we that a thorough re-evaluation on arm64 will not similarly
have the same outcome? IOW, what was the problematic part when doing the x86
evaluation, and how was that avoided when evaluating the arm64 implementation?
--
Cheers,
David
next prev parent reply other threads:[~2026-08-27 19:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 16:11 [RFC PATCH 00/18] mm: arm64: Add kernel replication feature Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 01/18] mm: arm64 add Kconfig option for kernel replication Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 02/18] arm64: align kernel text and rodata Nikita Panov
2026-08-27 17:35 ` Lorenzo Stoakes (ARM)
2026-08-27 16:11 ` [RFC PATCH 03/18] mm: allow per-NUMA node local P4D/PUD/PMD/PTE allocation Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 04/18] arm64: add arch callbacks for kernel replication Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 05/18] mm: per-NUMA node replication core infrastructure Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 06/18] mm: add support of memory protection for NUMA replicas Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 07/18] arm64: " Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 08/18] mm: set memory permissions for BPF handlers replicas Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 09/18] mm: add replicas allocation support for vmalloc Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 10/18] arm64: enable per-NUMA node kernel text and rodata replication Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 11/18] mm: " Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 12/18] arm64: make power management aware about kernel replication Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 13/18] arm64: make kernel text patching aware about replicas Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 14/18] arm64: add correct alignment to kimage in efi code Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 15/18] arm64: add support of NUMA replication for ptdump Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 16/18] arm64: add kernel modules text and rodata replication support Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 17/18] mm: init kernel modules with " Nikita Panov
2026-08-27 16:11 ` [RFC PATCH 18/18] mm: introduce kernel cmdline option "kernel_replication=" Nikita Panov
2026-08-27 17:25 ` [RFC PATCH 00/18] mm: arm64: Add kernel replication feature Lorenzo Stoakes (ARM)
2026-08-27 19:04 ` David Hildenbrand (Arm) [this message]
2026-08-27 19:11 ` Matthew Wilcox
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=bbd45126-8d43-40eb-8a69-a7fb6d2378f1@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=artem.kuzin@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=liam@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=ljs@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=panov.nikita@huawei.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox