linux-kernel - Re: [RFC GIT PULL] perf/trace/lock optimization/scalability improvements

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: <20100204063306.GA12807@elte.hu>
Date:	Thu, 4 Feb 2010 07:33:06 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Paul Mackerras <paulus@...ba.org>,
	Hitoshi Mitake <mitake@....info.waseda.ac.jp>,
	Li Zefan <lizf@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [RFC GIT PULL] perf/trace/lock optimization/scalability
 improvements


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> On Wed, Feb 03, 2010 at 11:33:16AM +0100, Peter Zijlstra wrote:
> > On Wed, 2010-02-03 at 10:14 +0100, Frederic Weisbecker wrote:
> > > - event injection support
> > 
> > I like the idea, I'm just not sure about the name and API details.
> >
> > I would like to call it something like collection support, and the API 
> > should have an iterator like interface.
> > 
> > That is, it should not blindly dump all events from a collection at once, 
> > praying the output buffer is large enough, but either dump a specified 
> > number and/or stop dumping when the buffer is full. Allowing a second 
> > invocation to continue where it left off after the buffer content has 
> > been consumed.
> 
> 
> Yeah I agree. But my worry is there are induced races in this scheme. But 
> probably tight enough that we don't care much.
> 
> Consider dumping the task list content:
> 
> A -> B -> C -> D
> 
> You open a "task" event. And ask to inject it one by one,
> you first dump A, and B disappear, then you'll miss it
> but you can still get C and D if they don't disappear.
> 
> As I said it is tight enough that we don't care. If B disappears
> so early, it means it won't have a determinant role in the profiling
> anyway (at worst few isolated events in the beginning).

We probably dont care - /proc is racy in the same fashion (you can miss 
tasks), still 'top' has been able to cope for a decade.

If we cared, it would be possible to construct a dump-collection-state 
sequence along the lines of:

 activate init/deinit events
 initiate dump

anything that got missed by the dump will be covered by the init/deinit event 
flow. In that sense it's important that init/deinit and dumping uses similar 
state structure - possibly the same event (as your solution did).

A 'dump' of a collection is basically the artificial replay of all its init 
events.

	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/