lkml.org 
[lkml]   [2023]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Direct rdtsc call side-effect
On Thursday, June 1st, 2023 at 1:31 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> What about kernel based emulation? You could tie it into user_dispatch
> and have a user_dispatch tsc offset.
>

> So regular kernel emulation simply returns the native value (keeps the
> VDSO working for one), but then from a user_dispatch range, it returns
> +offset.
>

> That is; how slow is the below?

It's around 1800-1900 clock cycles on this system (modified patch attached, compile fix + rdtscp support).

It's definitely better than the userspace signal handler (20x vs 100x). Also compared to reading one of the clock_gettime() clocks when current_clocksource is 'hpet', it's about twice as fast. So that's at least in the realm of being usable.

Since faulting would still make the vDSO clocks go through this path we'd have to be careful that whatever offsets we throw into this path don't affect the correctness of the other clocks.[unhandled content-type:application/octet-stream][unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2023-06-01 23:42    [W:0.094 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site