Re: Negative values in /proc/latency_stats

From: Arjan van de Ven
Date: Tue Feb 03 2009 - 11:34:36 EST


On Mon, 2 Feb 2009 20:55:45 -0800
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

[ I'm on a plane and writing a patch to fix some of the issues you
mention; I need to be tethered to test before sending]
>
> - It implements an up-to-1536-loops loop followed by an
> up-to-384-loops loop on a scheduler hotpath.
>
> All under spin_lock_irqsave()!

while you mention the theoretical worst case scenario numbers, the
reality isn't this bleak. it's a linear array that stores a chain, and
yes, the chain is searched lazy. but... the chain is stored "most
unique -> least unique", so typical complexity is a lot lower than what
you mention. And it is also only on when you are actually actively
tracing.

>
> - store_stacktrace() unnecessarily initalises trace.skip.

fixed in patch

>
> - account_scheduler_latency() should be an inline:
>
> if (unlikely(latencytop_enabled))
> __account_scheduler_latency(...);

borderline but fair; function calls are cheap (or even free in some
cases) but this one is in such a hotpath that this optimization makes
some sense.
>
> - ditto clear_all_latency_tracing()

this one is only called in slowpaths, so I wouldn't think this makes
sense.
>
> - it's schizophrenic in its placement of spaces around semicolons in
> `for' statements.

fixed in patch

>
> - it seems to only be implemented if CONFIG_FAIR_GROUP_SCHED=y.

this is a misunderstanding; sched_fair.c is not related to the fair
GROUP scheduler. It is the normal scheduler policy.

>
> - lstats_fops should be const.

fixed

> And it emits negative numbers too ;)

the problem with this one is that the numbers probably really ARE
negative... (but i need to test some more)
If time goes backwards during idle, the sleep time is considered
negative.... which I can understand will confuse humans.
The alternative possibility would be that we had a several-minutes
latency, which I consider unlikely.... the worst latency I've seen
under normal load is in the 10 second range, not the
hundreds-of-seconds or thousands-of-seconds range. And you'd think
people would notice such latencies and complain.

I'll see if I can just discard the "time goes backwards" cases rather
than propagating the insanity to userspace.


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/