linux-kernel - Re: Negative values in /proc/latency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Feb 2009 07:19:27 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Corrado Zoccolo <czoccolo@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Negative values in /proc/latency_stats

On Mon, 2 Feb 2009 20:55:45 -0800
Andrew Morton <akpm@...ux-foundation.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/