linux-kernel - Re: [RFC/Requirements/Design] h/w error reporting

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: <20101110184105.GH22410@elte.hu>
Date:	Wed, 10 Nov 2010 19:41:05 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	"Luck, Tony" <tony.luck@...el.com>, linux-kernel@...r.kernel.org,
	ying.huang@...el.com, bp@...en8.de, tglx@...utronix.de,
	akpm@...ux-foundation.org, mchehab@...hat.com,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [RFC/Requirements/Design] h/w error reporting

* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> On Wed, 2010-11-10 at 13:05 -0500, Steven Rostedt wrote:
> 
> > Peter said at LPC that the perf buffering system was not designed to handle high 
> > speed tracing. But he also said he does not like the way the ftrace buffering 
> > works.
> 
> You're not very good at listening, I said the perf infrastructure and event 
> handling mechanism isn't geared towards full throughput but instead on sampling.

Note that even that is an implementational detail that can be changed: even with a 
sampling model the sampling bits are in a flag word, so common combinations can be 
checked for quickly and open-coded into flat fall-through code - if the sample 
decoding ever shows up as overhead. (It doesnt even need any ABI changes.)

So it's a non-issue.

> There is lots of code between getting the event and landing it in the buffer. The 
> buffer itself is perfectly suited for high speed low overhead stuffs, the perf 
> data format possibly not because its not bitfield happy.

Even that can be tweaked via allowing more compressed records. I doubt it will help 
as much, but it's still an incremental change that can be validated carefully.

Fact is that we have an ABI, happy users, happy tools and happy developers, so going 
incrementally is important and allows us to validate and measure every step while 
still having a full tool-space in place - and it will help everyone, in addition to 
the ftrace/lttng usecases.

We'll need to embark on this incremental path instead of a rewrite-the-world thing. 
As a maintainer my task is to say 'no' to rewrite-the-world approaches - and we can 
and will do better here.

Thanks,

	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/