HI Neil,

thanks for the explanations. I tried to understand the reason for the
"bad" benchmark numbers during my direct IO write tests for my rmw
patch. I only choose it to avoid caching side effects. Even with 64
threads there is still a large gap to the theoretical maximum. So I
reduced the test to 1 writer and took some time to have a look how
raid5.c handles sync/direct writes. See my other post with only 5MB/s
4K direct writes to ramdisk backed raid5 md.

With that insight I started to compare it to raid1.c. After some
iterations it came to my mind that the empty raid5d() runs between
two sync writes might give extra latency and so I looked for corners
where md_wakeup_thread() might be unnecessary. The result are
the questions above.

I'll give the clear_bit(THREAD_WAKEUP,...) a try.

Markus

Just an all-clear response. The error I was analyzing came from my
Virutalbox test environment. With more than one CPU activated
process synchronzation seems to face high synchonization penalties
between make_request() and raid5d(). Switching back to real 
hardware with /dev/ramX shows normal throughput.  

A lot to wonder about when testing the kernel ...

Markus