gmirror 'load' algorithm (Was: Re: siis/atacam/ata/gmirror
8.0-BETA3 disk performance)
000.fbsd at quip.cz
Thu Dec 3 07:37:13 UTC 2009
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:
> 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.
More information about the freebsd-current