linux-kernel - Re: [PATCH] lockdep: Make lockstats counting per cpu

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] [day] [month] [year] [list]

Date:	Tue, 6 Apr 2010 11:25:45 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] lockdep: Make lockstats counting per cpu

On Tue, Apr 06, 2010 at 10:46:27AM +0200, Peter Zijlstra wrote:
> On Tue, 2010-04-06 at 00:10 +0200, Frederic Weisbecker wrote:
> > Locking statistics are implemented using global atomic variables.
> > This is usually fine unless some path write them very often.
> > 
> > This is the case for the function and function graph tracers
> > that disable irqs for each entry saved (except if the function
> > tracer is in preempt disabled only mode).
> > And calls to local_irq_save/restore() increment hardirqs_on_events
> > and hardirqs_off_events stats (or similar stats for redundant
> > versions).
> > 
> > Incrementing these global vars for each function ends up in too
> > much cache bouncing if lockstats are enabled.
> > 
> > To solve this, implement the debug_atomic_*() operations using
> > per cpu vars.
> > 
> > 
> 
> So I really have to ask, why?
> 
> This is CONFIG_DEBUG_LOCKDEP code, so its default off, and used to debug
> lockdep. Debug code should be as simple as possible, and preferably
> should not care about performance where possible.
> 
> So why complicate this?
> 


Also at worst it adds no more than 20 lines of code...

--
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/