Re: [patch V4 00/36] rseq: Optimize exit to user space

[Jens Axboe <axboe@kernel.dk>]

On 9/10/25 8:45 AM, Michael Jeanson wrote:
> On 2025-09-10 09:55, Jens Axboe wrote:
>> On 9/8/25 3:31 PM, Thomas Gleixner wrote:
>>> For your convenience all of it is also available as a conglomerate from
>>> git:
>>>
>>>      git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git rseq/perf
>>
>> I used this branch for some quick testing. Since I last looked at the
>> rseq performance overhead, glibc must have improved a few things. FWIW,
>> box is running libc 2.41 at the moment. Test box is on debian unstable,
>> so gets frequent updates. In any case, for one of my usual kernel
>> overhead runs of checking running a basic IOPS based test, I see the
>> following on the stock (-rc5 + 6.18 targeted changes) kernel running
>> that test:
>>
>> +    0.89%  io_uring  [kernel.kallsyms]  [k] __get_user_8
>> +    0.58%  io_uring  [kernel.kallsyms]  [k] __put_user_8
>> +    1.13%  io_uring  [kernel.kallsyms]  [k] __rseq_handle_notify_resume
>>
>> which is about 2.6% of purely rseq related overhead. Pulling in the
>> above branch and running the exact same test, all of the above are gone
>> and perusing the profile has nothing jump out at me in terms of shifting
>> those cycles to other bookkeeping.
>>
>> So yes, this work does make a very noticeable difference!
> 
> If you have time, could you also run the same test on this branch with glibc rseq registration disabled, just to see of there is some noticable differences.
> 
> To disable glibc automatic registration, just export this variable:
> 
>   GLIBC_TUNABLES="glibc.pthread.rseq=0"
> Thanks!

Running that same branch (-rc5 + pending stuff + tglx rseq changes)
doesn't show any noticeable differences in perf diff between having rseq
enabled or not via the above tunable. All I see are really minor
fluctuations between unrelated functions, as the run-to-run consistency
isn't entirely 0. But the trace doesn't have any signs of any
rseq/exit_to_usermode activity even with rseq enabled at this point.

-- 
Jens Axboe