From owner-freebsd-arch Wed Mar 21 13:45: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 1FF5C37B718 for ; Wed, 21 Mar 2001 13:44:58 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2LLhih02089; Wed, 21 Mar 2001 13:43:44 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103212143.f2LLhih02089@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: remind me again, why is MAXPHYS only 128k ? In-reply-to: Your message of "Wed, 21 Mar 2001 22:17:21 +0100." <89046.985209441@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Mar 2001 13:43:44 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200103212111.f2LLBSh01790@mass.dis.org>, Mike Smith writes: > >> > >> Are there any roadblocks for increasing MAXPHYS as a tweakable these > >> days, or is it still an "do not alter or ELSE..." #define ? > > > >There isn't much hardware out there that can do anything useful with an > >I/O larger than 128k. > > Well, while that is true, things like striping and raid-5 could benefit > from not being limited to a 128k stripesize for certain kinds of > bulk application. You're referring here to the interface between the bio layer and the RAID layer, rather than the actual limit on a physical I/O though. I realise that the RAID layer in question pretends to be an I/O layer, hence this being an issue. I think that MAXPHYS should become DFLTMAXPHYS, and the si_iosize_max field should be allowed to be an override in either direction, so that devices that *are* OK with larger transfers can actually take advantage of them. > I also belive tapes have been mentioned as a candidate for a larger > MAXPHYS. This I think has mostly been the case with SGI systems and large tape blocks, I think, but I don't recall whether 128k was enough. > >There was also a lengthy discussion on I/O > >saturation a little while back; the short answer is just that making it > >larger doesn't win anything significant, and may cause unacceptable > >latencies in some cases. > > Right, I'm not asking for a general increase, I'm asking if it can > be increased on a case-by-case basis or if the system will explode > for arcane architectural reasons if I double or quadruple it on > a particular system ? I don't believe that any of the previous discussion uncovered anything that would explode. You would probably want to check though. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message