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>