Messages in this thread | | | From | "Luck, Tony" <> | Subject | Re: [PATCH 1/2] x86/fpu: Measure the Latency of XSAVE and XRSTOR | Date | Sun, 24 Jul 2022 23:00:19 +0000 |
| |
RDTSC has returned values invariant of current frequency since Nehalem (modulo a few hiccoughs). So any CPU with XSAVE/XRESTOR should be safe to measure using TSC.
Sent from my iPhone
> On Jul 24, 2022, at 14:16, David Laight <David.Laight@aculab.com> wrote: > > From: Yi Sun >> Sent: 23 July 2022 09:38 >> >> Calculate the latency of instructions xsave and xrstor with new trace >> points x86_fpu_latency_xsave and x86_fpu_latency_xrstor. >> >> The delta TSC can be calculated within a single trace event. Another >> option considered was to have 2 separated trace events marking the >> start and finish of the xsave/xrstor instructions. The delta TSC was >> calculated from the 2 trace points in user space, but there was >> significant overhead added by the trace function itself. >> >> In internal testing, the single trace point option which is >> implemented here proved to be more accurate. > ... > > I've done some experiments that measure short instruction latencies. > Basically I found: > 1) You need a suitable serialising instruction before and after > the code being tested - otherwise it can overlap whatever > you are using for timing. > 2) The only reliable counter is the performance monitor clock > counter - everything else depends on the current cpu frequency. > On intel cpu the cpu frequency can change all the time. > Allowing for that, and then ignoring complete outliers, I could > get clock-count accurate values for iterations of the IP csum loop. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
| |