Re: [patch 00/61] ANNOUNCE: lock validator -V1

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> > We are pleased to announce the first release of the "lock dependency 
> > correctness validator" kernel debugging feature
> 
> What are the runtime speed and space costs of enabling this?

The RAM space costs are estimated in the bootup info printout:

 ... MAX_LOCKDEP_SUBTYPES:    8
 ... MAX_LOCK_DEPTH:          30
 ... MAX_LOCKDEP_KEYS:        2048
 ... TYPEHASH_SIZE:           1024
 ... MAX_LOCKDEP_ENTRIES:     8192
 ... MAX_LOCKDEP_CHAINS:      8192
 ... CHAINHASH_SIZE:          4096
  memory used by lock dependency info: 696 kB
  per task-struct memory footprint: 1200 bytes

Plus every lock now embedds the lock_map structure which is 10 pointers. 
That is the biggest direct dynamic RAM cost.

There are also a few embedded keys in .data but they are small.

The .text overhead mostly comes from the subsystem itself - which is 
around 20K of .text. The callbacks are not inlined most of the time - 
there are about 200 of them right now, which should be another +1-2K of 
.text cost.

The runtime cycle cost is significant if CONFIG_DEBUG_LOCKDEP [lock 
validator self-consistency checks] is enabled - then we take a global 
lock from every lock operation which kills scalability.

If DEBUG_LOCKDEP is disabled then it's OK - smaller than DEBUG_SLAB. In 
this case we have the lock-stack maintainance overhead, the irq-trace 
callbacks and a lockless hash-lookup per lock operation. All of that 
overhead is O(1) and lockless so it shouldnt change fundamental 
characteristics anywhere.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/