From owner-freebsd-arch@FreeBSD.ORG Tue Mar 23 00:33:55 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5B701065674; Tue, 23 Mar 2010 00:33:55 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB0D8FC27; Tue, 23 Mar 2010 00:33:54 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so242747eye.3 for ; Mon, 22 Mar 2010 17:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=1Uo69i8YIN6B8Csn1RSX/w1aTfU+eevdLHR211XGyMo=; b=Dwtj/qalff3+JWVjtxkn/OrncJCZmKWeSbh5v8LcevTNUrtSBvdeeh4CCzt1SCe97O 3qORmcEXLRERa5GdphmErgaBbk3jhWzeAnLotyI3hBCnqSmsinAsZy509rZYDCYLVezs v59Owjy6wmKA0Z9ng2bQrDhHZ8gZDDLq98nN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CUKFo5btO5fAcBkxKA8ltygcvdT8yAWIBpXxDo0QKBw0W78G+eVAqeIZeN+pTo8wdf ZyN53A6vbqsfAA4wn54XPCw9DEboF7rZyUeCw1voGig/ra7ohUjQzenEA5zzZmmN4g3r YLbd+VutfFyClTJRravICrGKspFX/kKjI9IJM= Received: by 10.213.99.135 with SMTP id u7mr427406ebn.36.1269304433778; Mon, 22 Mar 2010 17:33:53 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 14sm2427690ewy.10.2010.03.22.17.33.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 17:33:53 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BA80C6F.7050506@elischer.org> Date: Mon, 22 Mar 2010 17:33:51 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4BA633A0.2090108@icyb.net.ua> <5754.1269246223@critter.freebsd.dk> <20100322233607.GB1767@garage.freebsd.pl> In-Reply-To: <20100322233607.GB1767@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org, Poul-Henning Kamp , freebsd-current@FreeBSD.org, Alexander Motin , Andriy Gapon Subject: Re: Increasing MAXPHYS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 00:33:56 -0000 Pawel Jakub Dawidek wrote: > On Mon, Mar 22, 2010 at 08:23:43AM +0000, Poul-Henning Kamp wrote: >> In message <4BA633A0.2090108@icyb.net.ua>, Andriy Gapon writes: >>> on 21/03/2010 16:05 Alexander Motin said the following: >>>> Ivan Voras wrote: >>>>> Hmm, it looks like it could be easy to spawn more g_* threads (and, >>>>> barring specific class behaviour, it has a fair chance of working out of >>>>> the box) but the incoming queue will need to also be broken up for >>>>> greater effect. >>>> According to "notes", looks there is a good chance to obtain races, as >>>> some places expect only one up and one down thread. >>> I haven't given any deep thought to this issue, but I remember us discussing >>> them over beer :-) >> The easiest way to obtain more parallelism, is to divide the mesh into >> multiple independent meshes. >> >> This will do you no good if you have five disks in a RAID-5 config, but >> if you have two disks each mounted on its own filesystem, you can run >> a g_up & g_down for each of them. > > A class is suppose to interact with other classes only via GEOM, so I > think it should be safe to choose g_up/g_down threads for each class > individually, for example: > > /dev/ad0s1a (DEV) > | > g_up_0 + g_down_0 > | > ad0s1a (BSD) > | > g_up_1 + g_down_1 > | > ad0s1 (MBR) > | > g_up_2 + g_down_2 > | > ad0 (DISK) > > We could easly calculate g_down thread based on bio_to->geom->class and > g_up thread based on bio_from->geom->class, so we know I/O requests for > our class are always coming from the same threads. > > If we could make the same assumption for geoms it would allow for even > better distribution. doesn't really help my problem however.. I just want to access the base provider directly with no geom thread involved. >