Description:
Someone (probably Vadim Tkachenko) added a number of fields to mutex_t in order
to implement SHOW MUTEX STATUS. Especially the added mutex->count_using++
in mutex_enter_func() may contribute to the contention originally reported in Bug #22868.

How to repeat:
Run InnoDB on a multiprocessor system with multiple client connections. Observe the poor
scalability.

Suggested fix:
Enclose all added fields except count_os_wait in #ifdef UNIV_DEBUG and adapt the code.

To reduce the memory footprint further (to make mutex_t fit in fewer cache lines), also
remove mutex->level, mutex->magic_n and possibly mutex->lock_word from non-debug builds.

What speedup do you get with your patch ?

The patch at least saves about 80 bytes per buffer pool frame (in the newest 5.0 tree),
that is, 0.5 % of main memory. We do not yet have results if it affects scalability. Since
a mutex acquisition with Vadim's code caused two cache lines to be shipped, it might have
caused memory bus saturation.

Noted in 5.0.32 changelog.

The InnoDB mutex structure was simplified to reduce memory load.

Resetting report to In Progress pending decision about whether
to merge this patch into InnoDB 5.1. (The MySQL 5.0 patch has
been null-merged into MySQL 5.1.)

Marko,

It would be interesting to look at benchmarks in real enviroment and under
profiler tool like Intel Vtune.

Yes, I made that change, but I don't think it is the reason of bad scalability.

Vadim,

looks like this had nothing to do with the thread thrashing problems. But Marko's patch is
likely to save some computer memory system bandwidth, since there is less ping-pong of
cache lines between processors after Marko's patch.

Best regards,

Heikki

No further documentation needed.