Re: Negative values in /proc/latency_stats

[Corrado Zoccolo <czoccolo@gmail.com>]

On Wed, Feb 4, 2009 at 6:55 AM, Arjan van de Ven <arjan@infradead.org> wrote:
> On Tue, 3 Feb 2009 21:46:09 -0800
>
>> > + * Negative latencies (caused by time going backwards) are also
>> > explicitly
>> > + * skipped.
>>
>> Are we sure that this was the cause of the problem?
>
> not 100%, but if you add only positive numbers..... the only other
> option is an overflow.. but that would be such a huge latency that that
> is not very believable.
>

I can confirm that those huge latencies were not real. I was using the
machine, and it was responsive when this was measured.
Maybe I can suggest an other option.. To measure a latency, you have
to set up a variable when you enter a wait state, and compute the
difference when you exit the waiting. If you forget to initialize the
variable in one of the paths leading to the waiting, when you do the
difference, you can end up with negative (or more generally,
meaningless) numbers.
Anyway, skipping these numbers is surely better than propagating them
to userspace, if the cause cannot be found.

An other random thought: since tracing can have noticeable overheads,
as Ingo noticed, and is likely that distros will ship with various
tracers enabled in the kernel, I think the scheme used to control them
should be more robust.
Currently, you can enable/disable them by writing 1/0 in a pseudo-file
under /proc, but what happens if the userspace program fails to write
the 0 in the file after it finished tracing (it can even not have
chance to do if it is killed -9)? I propose that tracers like this
one, i.e. that record instantaneous data, should remain enabled only
while the userspace process keeps the fd opened. When it's closed (or
after a grace period), the tracer should be automatically disabled.

Corrado