On 2014-12-17, Luiz Capitulino <lcapitulino@xxxxxxxxxx> wrote:
> We're doing some scheduling latency measurements with KVM. While
> analyzing some traces and reading cyclictest code in the process, I
> found out that by default cyclictest uses the absolute time algorithm,
> which basically does:
>
> clock_gettime(&now)
> next = now + interval /* interval == 1000us */
> /* do some quick stuff */
> while() {
> clock_nanosleep(&next) /* ie. sleeps until now + 1000us, 'next' is abs */
> clock_gettime(&now)
> diff = calcdiff(now, next)
> /* update a bunch of stats and the histogram data, also
> check if we're finished */
> next += interval
> }
>
> Now, doesn't this mean that the timerthread will actually sleep less
> than interval?
Correct. In cyclictest you are not specifying sleep time. You are
specifing the wake interval.
> This is so because we have fixed sleeping points which don't take into
> consideration the sleeping latency
Sleep latency is taken into account. That is exactly what cyclictest
measures.
> nor the bunch of things the timerthread does (eg. update histogram).
cyclictest does not (and should not) care about this.
> If I'm making sense, won't this behavior cause better numbers to be
> reported?
Using _relative_ mode causes _worse_ numbers to be reported because it
assumes that a new relative time can be prepared and set
instantaneously, which is not correct. So you are not only measuring
sleep latency, but also mixing in timer setup duration. I think these
numbers would be misleading, since I would expect real-world RT projects
to be using absolute time.
Absolute (and relative) mode mixes in timer interrupt handling
duration. But that is appropriate here since we are not only interested
in how good the hardware timer is, but also how fast PREEMPT_RT can
allow software to respond to it.
John Ogness
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
