From owner-freebsd-arch@FreeBSD.ORG  Fri Apr  9 14:40:38 2010
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A42781065675
	for <arch@freebsd.org>; Fri,  9 Apr 2010 14:40:38 +0000 (UTC)
	(envelope-from avg@freebsd.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id E87808FC21
	for <arch@freebsd.org>; Fri,  9 Apr 2010 14:40:37 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
	[212.40.38.101])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA20904;
	Fri, 09 Apr 2010 17:40:26 +0300 (EEST)
	(envelope-from avg@freebsd.org)
Message-ID: <4BBF3C5A.7040009@freebsd.org>
Date: Fri, 09 Apr 2010 17:40:26 +0300
From: Andriy Gapon <avg@freebsd.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100319)
MIME-Version: 1.0
To: Rick Macklem <rmacklem@uoguelph.ca>
References: <4BBEE2DD.3090409@freebsd.org>
	<Pine.GSO.4.63.1004090941200.14439@muncher.cs.uoguelph.ca>
In-Reply-To: <Pine.GSO.4.63.1004090941200.14439@muncher.cs.uoguelph.ca>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: arch@freebsd.org
Subject: Re: (in)appropriate uses for MAXBSIZE
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 14:40:38 -0000

on 09/04/2010 16:53 Rick Macklem said the following:
> 
> 
> On Fri, 9 Apr 2010, Andriy Gapon wrote:
> 
>>
>> Nowadays several questions could be asked about MAXBSIZE.
>> - Will we have to consider increasing MAXBSIZE?  Provided ever
>> increasing media
>> sizes, typical filesystem sizes, typical file sizes (all that
>> multimedia) and
>> even media sector sizes.
> 
> I would certainly like to see a larger MAXBSIZE for NFS. Solaris10
> currently uses 128K as a default I/O size and allows up to 1Mb. Using
> larger I/O sizes for NFS is a simpler way to increase bulk data transfer
> rate than more buffers and more agressive read-ahead/write-behind.
> 
> I had assumed that MAXBSIZE is the largest sized block handled by the
> buffer cache? I have no idea what effect just increasing it has, but
> had planned on experimenting with it someday.

I have lightly tested this under qemu.
I used my avgfs:) modified to issue 4*MAXBSIZE bread-s.
I removed size > MAXBSIZE check in getblk (see a parallel thread "panic: getblk:
size(%d) > MAXBSIZE(%d)").
And I bumped MAXPHYS to 1MB.

Some results.
I got no panics, data was read correctly and system remained stable, which is good.
But I observed reading process (dd bs=1m on avgfs) spending a lot of time sleeping
on needsbuffer in getnewbuf.  needsbuffer value was VFS_BIO_NEED_ANY.
Apparently there was some shortage of free buffers.
Perhaps some limits/counts were incorrectly auto-tuned.

Also, I later tried to double MAXBSIZE value and got exactly the same results.
No panics, no corruptions.

But, of course, this doesn't mean that there are no problems.
Especially in the hardware drivers.

-- 
Andriy Gapon