Re: [RFC GIT PULL] perf/trace/lock optimization/scalabilityimprovements

[Ingo Molnar]

* Frederic Weisbecker <fweisbec@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/