From owner-freebsd-current Wed Jul 7 16:35:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 69C1A14CCB; Wed, 7 Jul 1999 16:35:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA94883; Wed, 7 Jul 1999 16:34:02 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 16:34:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907072334.QAA94883@apollo.backplane.com> To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <99Jul8.090830est.40363@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message