From owner-freebsd-current@FreeBSD.ORG Thu Dec 3 00:32:59 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B89961065672 for ; Thu, 3 Dec 2009 00:32:59 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD6C8FC2E for ; Thu, 3 Dec 2009 00:32:58 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.167.197]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id nB300dCn014028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 16:00:40 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <4B16FFA9.6070002@FreeBSD.org> Date: Wed, 02 Dec 2009 16:00:41 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Motin References: <4A9E8677.1020208@FreeBSD.org> <20090903002106.GB17538@dmr.ath.cx> <4AA0075A.5010109@FreeBSD.org> In-Reply-To: <4AA0075A.5010109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , "Derek \(freebsd lists\)" <482254ac@razorfever.net>, Emil Mikulic Subject: Re: gmirror 'load' algorithm (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 00:32:59 -0000 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