gmirror 'load' algorithm (Was: Re: siis/atacam/ata/gmirror
8.0-BETA3 disk performance)
Maxim Sobolev
sobomax at FreeBSD.org
Thu Dec 3 00:32:59 UTC 2009
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.
-Maxim
More information about the freebsd-current
mailing list