linux-kernel - Re: [PATCH] Separate lock events with types

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: <4BB9BD52.6060109@dcl.info.waseda.ac.jp>
Date:	Mon, 05 Apr 2010 19:37:06 +0900
From:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>, mingo@...e.hu,
	paulus@...ba.org, tglx@...utronix.de, gregkh@...e.de
Subject: Re: [PATCH] Separate lock events with types

On 03/27/10 08:33, Frederic Weisbecker wrote:
 > On Wed, Feb 24, 2010 at 06:02:46PM +0900, Hitoshi Mitake wrote:
 >> Sorry for my long silence...
 >>
 >> Thanks for Frederic's great work like trace_lock_class_init(),
 >> overhead of perf lock was reduced a lot.
 >> But still there is overhead which cannot be disregarded.
 >>
 >> So I'd like to suggest that separating lock trace events into each 
types of lock.
 >> e.g.
 >> 	trace_lock_acquire() ->  spin_trace_lock_acquire(), 
rwlock_trace_lock_acquire()
 >> I think that mutex and spinlock are completely different things.
 >> And as I describe below, filtering at recording phase can reduce 
overhead of tracing.
 >>
 >> CAUTION:
 >> This patch is the proof of concept. The way this patch employes
 >> is different from one I described above. This patch adds if statement
 >> before trace_lock_*(). Implementation of separating events per types 
will be
 >> a big one, so this is an only trial edition for performance 
improvements.
 >
 >
 > Instead of having one different event for each type of locks,
 > I would rather suggest to add a "lock type" field in the (future)
 > lock_init_class class. This requires we implement event injection
 > properly before.
 >
 > So if we store the lock type in the lockdep_map, we can just dump
 > the type on lock class initialization:
 >
 > - on register_lock_class
 > - on event injection to catchup with lock that have already registered
 >

Yeah, this is a smarter way than the one I suggested.

But specifying types of locks to focuse on will require special way.
I thought that ioctl() will make this type specifying possible,
but it will not match to other events...
e.g. perf record will be required dirty change for it.

Do you have any good ideas at this point?

Thanks,
	Hitoshi
--
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/