From owner-freebsd-current@FreeBSD.ORG Thu Dec 3 07:37:13 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 B025F1065695; Thu, 3 Dec 2009 07:37:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6441F8FC12; Thu, 3 Dec 2009 07:37:12 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 417A919E023; Thu, 3 Dec 2009 08:37:11 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 8D99919E019; Thu, 3 Dec 2009 08:37:08 +0100 (CET) Message-ID: <4B176AA4.60204@quip.cz> Date: Thu, 03 Dec 2009 08:37:08 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 MIME-Version: 1.0 To: Maxim Sobolev References: <4A9E8677.1020208@FreeBSD.org> <20090903002106.GB17538@dmr.ath.cx> <4AA0075A.5010109@FreeBSD.org> <4B16FFA9.6070002@FreeBSD.org> In-Reply-To: <4B16FFA9.6070002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, Alexander Motin , FreeBSD-Current , 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 07:37:13 -0000 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 Lachman