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

[Ingo Molnar]

* Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:

> Hi,
> 
> There are many things that happen in this patchset, treating
> different problems:
> 
> - remove most of the string copy overhead in fast path
> - open the way for lock class oriented profiling (as
>   opposite to lock instance profiling. Both can be useful
>   in different ways).
> - remove the buffers muliplexing (less contention)
> - event injection support
> - remove violent lock events recursion (only 2 among 3, the remaining
>   one is detailed below).
> 
> Some differences, by running:
> 	perf lock record perf sched pipe -l 100000
> 
> Before the patchset:
> 
> 	Total time: 91.015 [sec]
> 
> 	     910.157300 usecs/op
> 		   1098 ops/sec
> 
> After this patchset applied:
> 
> 	Total time: 43.706 [sec]
> 
> 	     437.062080 usecs/op
> 		   2288 ops/sec

Fantastic!

There's one area that needs more thought i think: the dump-all-classes 
init-event-injector approach. It is async, hence we could lose events if 
there's a lot of lock classes to dump. Plus we eventually want to use your 
injector approach for other things as well (such as to dump the state of a 
collection of tasks) - so i think we want it to be more synchronous.

One approach would be to allow a gradual read() deplete the dump. Also, i 
think the 'state dump' events should be separate from regular init events. 
Filters attached to these events will automatically cause the dumping to be 
restricted to the filter set. For example in the case of tasks one could dump 
only tasks from a particular UID - by adding a 'uid == 1234' filter before 
the dump (on a per tasks basis - so the filtering is nicely task local).

What do you think?

	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/