linux-kernel - Re: [RFC PATCH 1/3] Unified trace buffer

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: <20080925202054.GA4903@elte.hu>
Date:	Thu, 25 Sep 2008 22:20:54 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Tom Zanussi <zanussi@...cast.net>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer

* Ingo Molnar <mingo@...e.hu> wrote:

> cpu_clock() proved to be a good middle ground. I'm not a believer in 
> any of this stuff, i just react to how things behave in practice, as 
> none of this is really easy to get right from the theoretical angle.
[...]
> If sched_clock() is broken then the kernel wont work anyway. And i never 
> wanted to trace inside sched_clock() itself. [...]

note, CONFIG_LOCKSTAT - which hooks deep inside lockdep, uses 
cpu_clock() too for timings, for similar reasons. Lockdep and lockstat 
both have a very robust design and a very good track record to prove it.

you'd be correct in pointing out that we _do_ have a relatively high 
regression count in cpu_clock()/sched_clock(), but the reason for that 
is that its implementation balances on the narrow edge of doability. It 
implements a very unstable set of requirements: "absolutely fast" pitted 
against "as accurate as possible".

That is two conflicting requirements and it is a very fine line to walk 
and everyone tries to have their own variant of it and their own 
balance. We try as hard as possible to use the TSC even in face of 
C2/C3, cpufreq, unstable TSCs, etc. The moment we go too much towards 
performance we regress accuracy and hurt the scheduler's quality and 
vice versa.

and note that my years long experience in the tracing field show that it 
has a _very_ similar need for accuracy versus performance, so it was a 
good match for ftrace.

	Ingo
--
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/