linux-kernel - Re: [PATCH v6 2/2] Output stall data in debugfs

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]

Message-ID: <CAAuSN9256P3gYTgcFA9AQjZrBC_jX2miH2FrPLstY+Vu=pn1LA@mail.gmail.com>
Date:	Fri, 12 Aug 2011 12:46:47 -0700
From:	Alex Neronskiy <zakmagnus@...omium.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Don Zickus <dzickus@...hat.com>,
	Mandeep Singh Baines <msb@...omium.org>
Subject: Re: [PATCH v6 2/2] Output stall data in debugfs

On Fri, Aug 12, 2011 at 2:06 AM, Ingo Molnar <mingo@...e.hu> wrote:
> Well, but there are conceptual problems at the higher levels: the
> concept of recording a worst-case (or best-case) latency is not
> limited to the comparatively minor usecase of soft-watchdog stalls.
>
> We have numerous tracers in ftrace that output their own kinds of
> min/max latencies, with associated stack trace signatures.
>
> So the right approach would *not* be to add yet another
> special-purpose debugfs variant for this, but to integrate this
> capability into perf tracing. That way it would be useful for:
>
>  - soft stalls
>  - irq service latencies
>  - irq disable latencies
>  - preempt disable latencies
>  - wakeup latencies
>  - and much more: it could be used for just about any event that
>   measures some sort of latency.
>
> To implement it i'd first suggest to add a TRACE_EVENT() for the
> softwatchdog latencies, and then look at how a stack-trace attached
> to the worst-case latency could be emitted via the perf ring-buffer.
>
> We do something very, very similar for callchains already, so all the
> low level machinery is already there.
>
> Alex, would you be interested in taking a stab at this approach? Such
> an approach looks a *lot* more palatable from an upstream merge point
> of view and it would give you all the functionality that the current
> patches are providing you (and more).
>
> Thanks,
>
>        Ingo
The best data comes from real-world use, so we want this used in
production. We felt that ftrace would add excessive overhead and bog
down performance, whereas this random sampling approach is basically
free, especially considering it's piggybacking on watchdogs which are
already running anyway. Is our approach misguided? Is this not as
cheap as we think? Is tracing not as expensive as we think?
--
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/