Re: [RFC] in-kernel rseq

[Shrikanth Hegde <sshegde@linux.ibm.com>]

Hi Peter,

On 2/23/26 10:08 PM, Peter Zijlstra wrote:
> Hi,
> 
> It has come to my attention that various people are struggling with
> preempt_disable()+preempt_enable() costs for various architectures.
> 
> Mostly in relation to things like this_cpu_ and or local_.
> 
> The below is a very crude (and broken, more on that below) POC.
> 
> So the 'main' advantage of this over preempt_disable()/preempt_enable(),
> it on the preempt_enable() side, this elides the whole conditional and
> call schedule() nonsense.



This might be a very stupid question.

Why not just call preempt_enable_no_resched instead?

this_cpu operations would have disabled preemption so the per_cpu
structures are protected from thread migration right? intention
here is likely not to call schedule. No?

PS: Sorry for the long delay in response.

> 
> Now, on to the broken part, the below 'commit' address should be the
> address of the 'STORE' instruction. In case of LL/SC, it should be the
> SC, in case of LSE, it should be the LSE instruction.
> 
> This means, it needs to be woven into the asm... and I'm not that handy
> with arm64 asm.
> 
> The pseudo code would be something like:
> 
> 	current->sched_seq = &_R;
> 	...
> 
> _start:  compute per cpu-addr
> 	 load addr
> 	 $OP
> _commit: store addr
> 
> 	...
> 	current->sched_rseq = NULL;
> 
> 
> Then when preemption happens (from interrupt), the instruction pointer
> is 'simply' reset to _start and it tries again.
> 
> Anyway, this was aimed at arm64, which chose to use atomics for
> this_cpu. But if we move sched_rseq() from schedule-tail into interrupt
> entry, then this would also work for things like Power.
> 
> Anyway, just throwing ideas out there.
> 
>