From owner-freebsd-arch Wed Mar 21 13:51:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9F8FF37B719; Wed, 21 Mar 2001 13:51:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LLpii22172; Wed, 21 Mar 2001 13:51:44 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 13:51:44 -0800 (PST) From: Matt Dillon Message-Id: <200103212151.f2LLpii22172@earth.backplane.com> To: Poul-Henning Kamp Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89599.985211175@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200103212138.f2LLc8a21690@earth.backplane.com>, Matt Dillon writes: : :> In anycase, my suggestion would be to leave it alone and instead work on :> optimizing the RAW DEVICE I/O path to not be limited by MAXPHYS at all. :> Increasing it to 256K might be possible, but increasing it to 1MB is :> out of the question (insofar as being a default). : :Well, that is stuck on the b_pages field in the (p)buf's. I was wondering :if we should make that a ** instead of a *[] so that it could be sized :dynamically for pbufs. : :Hmm.... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 The pbuf's use a reserved chunk of KVM, so during kernel initialization you could pre-allocate a static pages[] array that covers the entire reserved space and then make b_pages a ** and simply point it into the static array as appropriate. The physical buffer subsystem would have to 'allocate' (aka reserve) variable sized blocks out of the KVM space rather then using a fixed block size, but that would be the only issue. We could almost certainly use a faked vm_map (like the buffer cache uses) to manipulate the space, especially now that Tor has cleaned it all up. There are a few uses of pbuf's (and normal bufs for that matter) where the KVA is ignored and a kernel module will stuff its own vm_page_t's into the pbuf. I have not researched all such occurances of these but I would not expect it to be difficult to 'fix'. If they're synchronous the local pages[] could be declared on the stack. I dunno. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message