On Tue, 28 Mar 2023 16:38:37 +0100, Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Tue, Mar 28, 2023, Marc Zyngier wrote: > > On Tue, 21 Mar 2023 19:10:04 +0000, > > Colton Lewis <coltonlewis@xxxxxxxxxx> wrote: > > > In context, I'm trying to measure the time it takes to write to a buffer > > > *with dirty memory logging enabled*. What do you mean by zero? I can > > > confirm from running this code I am not measuring zero time. > > > > See my earlier point: the counter tick is a few MHz, and the CPU > > multiple GHz. > > On x86, the system counter (TSC) counts at multiple GHz, so we > should be able to continue with that approach for x86. > > > So unless "whatever" is something that takes a significant time (several > > thousands of CPU cycles), you'll measure nothing using the counter. Page > > faults will probably show, but not a normal access. > > > > The right tool for this job is to use PMU events, as they count at the CPU > > frequency. > > Out of curiosity, what does the kernel end up using for things like ndelay()? I > tried to follow the breadcrumbs for ARM and got as far as arm_arch_timer.c, but > after that I'm more than a bit lost. That's where it ends. We use the counter for everything. Even on ARMv8.6+ HW that is supposed to give you a 1GHz counter, implementations are allowed to perform "lumpy" increments (50MHz counter with increments of 20 per tick, for example). M. -- Without deviation from the norm, progress is not possible.
