From owner-freebsd-arch Wed Mar 21 13:42:10 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 7710037B720 for ; Wed, 21 Mar 2001 13:42:08 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LLg1921851; Wed, 21 Mar 2001 13:42:01 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 13:42:01 -0800 (PST) From: Matt Dillon Message-Id: <200103212142.f2LLg1921851@earth.backplane.com> To: Poul-Henning Kamp Cc: mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89281.985210220@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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