[LITMUS^RT] Overhead measurement with switching frequencies
Andrea Bastoni
bastoni at sprg.uniroma2.it
Sat Nov 25 12:02:51 CET 2017
Apparently the reply-all only replied to Gabriel.
On 11/25/17 11:54, Andrea Bastoni wrote:
> Hi Gabriel,
>
> On 11/23/17 14:40, Gabriel Lozano wrote:
>> Hi all, I'm working on a DVFS scheduler prototype using LITMUS^RT as my main
>> platform.
>>
>> I wanted to know if LITMUS^RT mechanism for measuring overheads is still
>> reliable even when the frequency of the processor is constantly changing during
>> the schedule. Digging into the feather trace code, I found it relies on calls to
>> __native_read_tsc(), which I suppose triggers the rdtsc instruction.
> ^^^^^^^
> (you can check in the Linux's code how that's implemented ;)
>
> Yes, if you want to measure overhead in a lightweight way, you should use
> something with a low latency, and the per-cpu timestamp counter on x86 is
> appropriate for this. (See the original paper from Björn about Feather Trace.)
>
>> My x86_64 system features the constant_tsc flag, which according to
>> documentation means that working of the tsc goes unaffected by frequency changes
>> or sleep states. This way, is it safe to assume that the feather trace
>> infrastructure will work correctly even when switching frequencies? I suppose
>> overheads would have to be accounted for in terms of cycles instead of time.
>
> Recent x86 platforms (IIRC starting from Nehalem / Intel Core Duo) have an
> invariant TSC, whose frequency update is not affected by the processor power
> state. Note that the TSC is per-core, so there may be difference between reads
> on different cores (see the rtscp instruction).
>
> Note that, unless you're comparing deltas, or unless you're comparing against
> data that uses cycles, you should better convert the timestamp cycles data to
> e.g., nanoseconds or microseconds (cat /proc/cpuinfo tells you an AVG CPU
> frequency as computed by the linux kernel, you should check if this computation
> of the average CPU frequency fits your need.)
>
> BR,
Andrea
More information about the litmus-dev
mailing list