Maxim Sobolev wrote: > Alexander Motin wrote: >> I have played a bit with this patch on 4-disk mirror. It works better >> then original algorithm, but still not perfect. >> >> 1. I have managed situation with 4 read streams when 3 drives were >> busy, while forth one was completely idle. gmirror prefer constantly >> seek one of drives on short distances, but not to use idle drive, >> because it's heads were few gigabytes away from that point. >> >> IMHO request locality priority should be made almost equal for any >> nonzero distances. As we can see with split mode, even small gaps >> between requests can significantly reduce drive performance. So I >> think it is not so important if data are 100MB or 500GB away from >> current head position. It is perfect case when requests are completely >> sequential. But everything beyond few megabytes from current position >> just won't fit drive cache. >> >> 2. IMHO it would be much better to use averaged request queue depth as >> load measure, instead of last request submit time. Request submit time >> works fine only for equal requests, equal drives and serialized load, >> but it is actually the case where complicated load balancing is just >> not needed. The fact that some drive just got request does not mean >> anything, if some another one got 50 requests one second ago and still >> processes them. > > Can you try this one: > > http://sobomax.sippysoft.com/~sobomax/geom_mirror.diff > > It implements different logic - instead of looking for the time, it > checks the outstanding requests queue length and recently served > requests proximity to decide where to schedule requests. Have you any numbers from benchmarks for different type of load? (I will try it when I found some free time) Maybe both algorithms can be implemented, one as 'load-offset' and one as 'load-queue', so users can use which one is better for their workload. Miroslav LachmanReceived on Thu Dec 03 2009 - 06:37:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:58 UTC