Order of patches is:

show_patches.patch
microslow_innodb.patch
userstatv2.patch
microsec_process.patch
innodb_io_patches.patch
mirror_binlog.patch
mysqld_safe_syslog.patch
innodb_locks_held.patch
innodb_show_bp.patch
innodb_check_fragmentation.patch
innodb_io_pattern.patch
innodb_fsync_source.patch
innodb_show_hashed_memory.patch
split_buf_pool_mutex_fixed_optimistic_safe.patch
innodb_rw_lock.patch

Ok Thank you for sharing results!
We are looking to fix some regressions in -percona.

I think comments there not good place to communicate back and forth – I have some questions to you – can you drop me email to vadim at percona

I have:
#define HAVE_ATOMIC_BUILTINS 1

so it should be ok for -highperf effect

Few numbers so well comparing “standard” vs “persona” MySQL 5.0.67:
– data load is at least x2 times faster with “persona”
– index creation is at least x2 times faster with “persona”

Workload tests – my initial “much worse” observation was due cold cache – now each test is replayed several times to compare “apples to apples”..

But so well:
– read-only test:
– 3000 tps max for “persona”
– 3500 tps max for “standard”

– read+write test:
– 2800 tps for “persona” (+ much more stable)
– 2500 tps for “standard”

But testing is still continuing- I’ve found MySQL is keeping workload much(!) more better with “nnodb_thread_concurrency=8″ rather “0″ – it creating so many mutex contentions during processing – seems it’s better to limit an active number of running threads from the InnoDB side rather to leave them in the savage battle

Rgds,
-Dim

Actually I think the only userstats can be problem, as Google confirmed mutex contention.

But this is task for you to found regression, I hope you will solve it

Honestly, “I think (The other people may not so)”,
-percona version (even -percona-highperf) may be always slower than normal MySQL.
We should choose and discard patches of -percona to get more performance…
Some of the patches must cause performance regression.

And,

I think you should check the build tree of -highperf if you use.

innobase/ib_config.h contains
#define HAVE_ATOMIC_BUILTINS 1
or
#define HAVE_ATOMIC_BUILTINS 0

If it is “0″, there may be almost no effect of -highperf.
It means the GCC doesn’t support the builtin feature of atomic operations.

My DB server: 48 cores, SPARC64-VII 2500Mhz, 192GB RAM
Injector is a similar server; Gbit connection between injector and DB;

Workload:
1. read-only: 2 simple selects per “transaction”
2. read-write: 2 simple selects per “transaction” + delete/insert/update of a single row

no logical contention between queries;
load is progressively increased from: 1 2 4 8 16 32 64 128 and 256 concurrent sessions;

Test is running currently (comparing 5.0.67, 5.1.29, 6.0.7, and 5.0.67-persona); I’ll give you a real numbers by Monday.

Rgds,
-Dim

5.1.28 actually has very limited set of patches.

We should have more for 5.1.30.

I’m really looking forward to seeing a 5.1.30 percona build in the very near future, as certain people are promising this will be GA in the next couple of weeks.

To provide optimal my.cnf we should know your workload and server characteristics.
And what is much worse – can you show some numbers ?