Date: Wed, 21 Mar 2001 14:14:31 -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: <200103212214.f2LMEV023966@earth.backplane.com> References: <89775.985211665@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:In message <200103212151.f2LLpii22172@earth.backplane.com>, Matt Dillon writes:
:
:> 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.
:
:Physio is actually one of these...
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:phk@FreeBSD.ORG | TCP/IP since RFC 956
Yah. But it's also synchronous I believe. So you can declare
a pages[] array on the stack with the correct size and assign the
pbuf's b_pages to it. We still have to be careful in regards
to kernel stack growth. 1MB/4096 = 256 elements = 1K of stack.
That's a big problem.
We could also create a pool of vm_page_t slots and then allocate
blocks of slots out of the pool, though if we do that we have
to worry about what happens if the pool runs out. The zalloc memory
allocator mechanism I wrote for libstand (see /usr/src/lib/libstand/zalloc.c)
would be perfect for this sort of pool allocator.
-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?200103212214.f2LMEV023966>