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

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: <20091113092612.GA26185@elte.hu>
Date:	Fri, 13 Nov 2009 10:26:12 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Subject: Re: [PATCH] tracing: Rename lockdep event subsystem into lock


* Peter Zijlstra <peterz@...radead.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
--
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/