From owner-freebsd-arch Mon Feb 5 12: 8:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 1ACCE37B491; Mon, 5 Feb 2001 12:08:01 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f15K6bO49659; Mon, 5 Feb 2001 13:06:54 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200102052006.f15K6bO49659@aslan.scsiguy.com> To: Randell Jesup Cc: Matt Dillon , Matthew Jacob , Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-Reply-To: Your message of "05 Feb 2001 12:30:50 EST." Date: Mon, 05 Feb 2001 13:06:37 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> (2) Modify the 'struct buf' b_pages[] array to instead be a pointer >> to an array. Include the original static array under another name >> for compatibility purposes and have the init code default to >> assigning b_pages to the original embedded static array. >> >> Then the physio code could be adjusted to dynamically MALLOC the >> necessary pages array if the static one in the supplied buffer is >> insufficient. > > So, how reasonable is this? It seems like a pretty good solution, >but I'm far from up-to-speed on the internals here. I'd rather allow bufs (or bios) to be chained and let the block devices decide how to break them up. This simplifies the clustering code too as you avoid all of the VM operations to combine bufs into a single cluster buf. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message