Re: [PATCH 0/2] mm: memory-failure: fix HWPoison flag race with non-atomic page flag ops

From: David Hildenbrand (Arm)

Date: Mon Jun 29 2026 - 17:22:34 EST


[...]

>
> And again, I'm really not sure fixing a theoretical race when memory
> is failing is worth slowing the world by 0.1-1% for.
>

Fully agreed. I was hoping RCU was cheaper (I mean, we were once told that RCU
read side locking is essentially for free ... well in some configs :) )

The question if we could optimize it reasonably enough ...

>
> From what I saw in my testing, if we allocate 4k pages
> it's hidden by the overhead. With hp and thp it's measureably
> worse than rcu on !preempt config.

... for example, by doing the rcu read lock + unlock around the

for (i = 1; i < (1 << order); i++) {

loop on the alloc path. But I suspect it's not going to make that much of a
difference.

I concluded, similar to Andi, that stop_machine() is too big of a hammer.

I wonder if something could be built out of preempt_disable() and sync SMP
calls. hmm :(

--
Cheers,

David