Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Dec 2009 16:00:41 -0800
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        Alexander Motin <mav@FreeBSD.org>
Cc:        FreeBSD-Current <freebsd-current@FreeBSD.org>, "Derek \(freebsd lists\)" <482254ac@razorfever.net>, Emil Mikulic <emikulic@gmail.com>
Subject:   Re: gmirror 'load' algorithm (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance)
Message-ID:  <4B16FFA9.6070002@FreeBSD.org>
In-Reply-To: <4AA0075A.5010109@FreeBSD.org>
References:  <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>	<4A9E8677.1020208@FreeBSD.org> <20090903002106.GB17538@dmr.ath.cx> <4AA0075A.5010109@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B16FFA9.6070002>