On Wed, 5 Aug 2026 14:07:01 +0200
"David Hildenbrand (Arm)" [off-list ref] wrote:
On 8/3/26 15:59, Christophe Leroy (CS GROUP) wrote:
quoted
Le 14/07/2026 à 16:03, Kevin Brodsky a écrit :
quoted
mm code often needs to know whether some mm represents a kernel or
user address space. This is currently done by comparing the mm
pointer with &init_mm; besides not being particularly elegant, this
ignores the fact that other mm's (e.g. efi_mm) may also represent
parts of the kernel address space.
Introduce a new mm flag MMF_KERNEL and set it for init_mm.
Subsequent patches will use this flag to replace comparisons with
&init_mm. No functional change is introduced for now.
Did you consider performance impact ? This test is usually done in quite
critical memory handling functions.
init_mm is known at link time. Before your patch 08/22 there is just a
comparison of mm (r3) with a constant (loaded in r10):
c0014048 <assert_pte_locked>:
c0014048: 3d 40 c1 09 lis r10,-16119
c001404c: 39 4a 03 98 addi r10,r10,920
c0014050: 7c 03 50 00 cmpw r3,r10
c0014054: 4d 82 00 20 beqlr
...
After patch 08/22 we have, it first checks that mm is not 0, then it loads the
word located at mm+528 then AND it with 0x1. This load might be costly.
c0014048 <assert_pte_locked>:
c0014048: 2c 03 00 00 cmpwi r3,0
c001404c: 7c 85 23 78 mr r5,r4
c0014050: 41 82 00 10 beq c0014060 <assert_pte_locked+0x18>
c0014054: 81 23 02 10 lwz r9,528(r3)
c0014058: 71 29 00 01 andi. r9,r9,1
c001405c: 4c 82 00 20 bnelr
Is that a real problem, though?
The cost of the read is likely to matter most if the branch gets mispredicted.
I'd also guess the mm isn't usually NULL - so that branch needs to statically
predicted correctly as well.
I'd also not assume that the mm is in the cache (unless the surrounding code
has already accessed it), the L1 data caches are small.
David
What we could do is to just keep the == &init_mm check internally on configs
where we know that there is only a single such MM context.
Just a thought.