Date: Wed, 21 Mar 2001 13:51:44 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? Message-ID: <200103212151.f2LLpii22172@earth.backplane.com> References: <89599.985211175@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103212151.f2LLpii22172>