Date: Wed, 21 Mar 2001 13:42:01 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? Message-ID: <200103212142.f2LLg1921851@earth.backplane.com> References: <89281.985210220@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
:Yeah, it's a mistake for struct buf/bio to use a fixed array of pages
:(b->b_pages) If we made that a ** instead we could have a variable
:MAXPHYS...
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:phk@FreeBSD.ORG | TCP/IP since RFC 956
Remember that allocating struct buf's cannot block in MALLOC or anything
like that. It is difficult to deal with struct buf exhaustion in
vfs/bio. We can't add any new blocking conditions anywhere and still
have a stable system.
There are a couple of possible solutions, including preallocating a
VM pages[] array of pointers that covers the *ENTIRE* struct buf KVA space
and then simply assigning the appropriate point to a vm_page_t **b_pages
element in the struct buf at the point where we associate KVM with the
struct buf. This would give us maximum flexibility.
Perhaps a pages[] array covering the entire kernel VM space would be an
even better solution. 1G / 4K x 4 bytes = 1MB. Not a big deal.
-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?200103212142.f2LLg1921851>