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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Feb 2010 11:26:11 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.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:

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