Re: [PATCH] tracing: Rename lockdep event subsystem into lock

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, 2009-11-13 at 10:06 +0100, Frederic Weisbecker wrote:
> > Lockdep events subsystem gathers various locking related events such
> > as a request, release, contention or acquisition of a lock.
> > 
> > The name of this event subsystem is a bit of a misnomer since these 
> > events are not quite related to lockdep but more generally to 
> > locking, ie: these events are not reporting lock dependencies or 
> > possible deadlock scenario but pure locking events.
> 
> But in order to get them you need pretty much all of lockdep, except 
> PROVE_LOCKING. You get all the lock debugging, the lock tracking, the 
> struct dep_map bloat etc.
> 
> But sure, I don't mind renaming the category.

Yeah, i'd prefer it this way. You are right that most of lockdep.o is 
still there, but most of the lockdep _overhead_ shouldnt be there - no 
hashing, no tracking, etc.

it's still nonzero - see 'perf top' of a hackbench session, with 
LOCK_STAT enabled and PROVE_LOCKING disabled:

------------------------------------------------------------------------------
   PerfTop:   14059 irqs/sec  kernel:99.8% [1000Hz cycles],  (all, 16 CPUs)
------------------------------------------------------------------------------

             samples  pcnt function                                 DSO
             _______ _____ ________________________________ ________________

             7320.00  7.9% sched_clock_local                [kernel]
             7217.00  7.8% lock_acquired                    [kernel]
             5768.00  6.2% trace_hardirqs_off               [kernel]
             4562.00  4.9% __lock_acquire                   [kernel]
             4304.00  4.6% lock_release                     [kernel]
             3838.00  4.1% lock_acquire                     [kernel]
             3833.00  4.1% look_up_lock_class               [kernel]
             3561.00  3.8% cpu_clock                        [kernel]
             3283.00  3.5% start_critical_timing            [kernel]
             2992.00  3.2% __alloc_skb                      [kernel]
             2680.00  2.9% acpi_pm_read                     [kernel]
             2498.00  2.7% sched_clock                      [kernel]
             2409.00  2.6% copy_user_generic_string         [kernel]
             2016.00  2.2% lock_release_holdtime            [kernel]
             1899.00  2.0% sched_clock_cpu                  [kernel]

but i think those should be gradually eliminated and improved, as lock 
statistics could become a quite popular thing.

If the tracepoints are named 'lock', people will expect less overhead, 
and might end up fixing/improving it. If it's named 'lockdep' on the 
other hand, the expectation is higher overhead.

	Ingo