Re: [RFC] in-kernel rseq

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

Hi Heiko.

On 4/15/26 2:21 PM, Heiko Carstens wrote:
> On Fri, Apr 10, 2026 at 11:27:50PM +0530, Shrikanth Hegde wrote:
>> 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?
> 
> Doing that would make it unpredictable when the kernel is preempted for
> cases where TIF_PREEMPT is set while within a code section which has
> preemption disabled and where preemption is enabled again without checking
> for TIF_PREEMPT.


Ok. I discussed this with peter too. Likely we need to do something using paca.
I will go through your implementation.

While there, maybe move preempt count to paca too which has been long pending.
atleast for ppc64.