| Date | Fri, 23 Jun 2006 11:41:26 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 00/61] ANNOUNCE: lock validator -V1 |
| |
* Andrew Morton <akpm@osdl.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|