Skip site navigation (1)Skip section navigation (2)
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>