Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Jul 1999 16:34:02 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Cc:        freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Heh heh, humorous lockup
Message-ID:  <199907072334.QAA94883@apollo.backplane.com>
References:   <99Jul8.090830est.40363@border.alcanet.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
:It appears we're rapidly approaching the point where 32-bits isn't
:enough.  We could increase KVA - but that cuts into process VM space
:(and a large machine is likely to have large processes).

    True, though what we are talking about here is scaling issue with
    main memory.  We should be able to fit everything necessary to
    support 4GB of ram into a 1GB of KVM.  That we aren't means we
    are doing something wrong somewhere.

:The other option is moving away from a flat memory model: How about
:putting some of the larger kernel-only data-structures into another
:segment?  The downside is that unless we want to start passing `far'
:pointers around (which is both ugly and inefficient), we need to
:make the pointer address space transparent to the compiler.

    I don't think it is worth it.  We would then have to switch the MMU
    context just going from user to supervisor mode.  It would not be
    too hard to do that since all data movement from the user address space
    is encapsulated, but it just wouldn't be worth the overhead.

    The biggest thorn in our side is the filesystem buffer cache.  If we
    could somehow make the KVA mappings apply only to I/O in progress
    and actively retrieved buffers (getblk()), we would have plenty of KVA
    space left over for other things.  Right now it is fairly expensive
    to KVA map and unmap the filesystem buffer's b_data pointer.  I'm not
    sure why.

:Of course, with proper data-hiding, this exercise is fairly trivial -
:only the functions that physically reference the object need to know
:where it is.  But I don't think the kernel is structured in this way
:(for good and valid reasons - CS theoreticians notwithstanding).  And
:any bugs (like `cheating' by not accessing data through the approved
:mechanisms) will lead to fairly obscure panics (the address is
:perfectly valid - it's just the wrong segment).
:
:Peter

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907072334.QAA94883>