From owner-freebsd-hackers Wed Jul 7 16:26:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 1FBBB14D34; Wed, 7 Jul 1999 16:26:17 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40363>; Thu, 8 Jul 1999 09:08:30 +1000 Date: Thu, 8 Jul 1999 09:26:09 +1000 From: Peter Jeremy Subject: Re: Heh heh, humorous lockup To: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Message-Id: <99Jul8.090830est.40363@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > Yes, I do - at least with the 512MB figure. That would be half of the 1GB >KVA space and large systems really need that space for things like network >buffers and other map regions. Matthew Dillon wrote: > What would be an acceptable upper limit? 256MB? 128MB? The test > I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area > before the number of vnodes stabilized, on a 1GB machine. I would say > that a 128MB upper limit would be too small for a 4G machine. A 256MB > limit ought to work for a 4G machine 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). 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. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message