OK, here we go again. The patch has been updated to 2.6.9-rc2 and mdadm 1.7.0, and I've implemented the suggestions you've made below...
Patches: http://parisc-linux.org/~jejb/md_bitmap/
Well, I ran some simple write performance benchmarks today and I was stunned to find the bitmap performance was terrible. After debugging a while, I realized the problem was having the bitmap daemon do the wait_on_page_writeback...if the daemon got caught at the wrong time, it could take quite a while to come back around and do the writeback. So, I added yet another thread, the bitmap writeback daemon (whose sole purpose is to wait for page writebacks) and now things are running excellently. My simple benchmarks, which previously showed about a 25-30% slowdown when using a bitmap vs. not using one, now show only a 4% slowdown, which is pretty close to the margin of error in the test itself. Check out the new patch here:
http://parisc-linux.org/~jejb/md_bitmap/md_bitmap_2_37_2_6_9_rc2.diff
Thanks again, Paul
Neil Brown wrote:
This is definitely heading in the right direction. However I think you have missed some of the subtleties of plugging.
[snip]
That should then have the bitmap updates happening before the data updates, and should cluster bitmap updates better.
OK, I've fixed that.
The next step would be to stop write_page from being synchronous - I'm not comfortable about ->unplug-fn having to wait for disk io.
Well, it still does have to wait for the bitmap writes to complete before letting the regular writes go, but I see your point about the writes being submitted simultaneously (nearly) rather than being completely serialized.
This looks to be quite awkward as there is not call-back that happens when writeback on a page is completed. You need to have a kernel thread to wait for the pages to complete. I would get the bitmap_daemon to do this.
OK, this is what I've done...there didn't seem to be a better place to do it.
Does that make sense?
Certainly does, and seems to work... - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
