Date: Thu, 21 Jun 2001 09:24:37 -0300 (BRST) From: Rik van Riel <riel@conectiva.com.br> To: Terry Lambert <tlambert2@mindspring.com> Cc: Matt Dillon <dillon@earth.backplane.com>, "Ashutosh S. Rajekar" <asr@softhome.net>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: max kernel memory Message-ID: <Pine.LNX.4.33.0106210917160.6263-100000@duckman.distro.conectiva> In-Reply-To: <3B3190D9.D38B903D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Jun 2001, Terry Lambert wrote: > Back to swapping socket structures... > > You could swap them if you wanted to give up some KVA > space to be able to do it. Which is a problem, especially for Linux. The problem here is that there are x86 machines around with 64GB of RAM. Linux has just under 1GB of KVA and FreeBSD has (IIRC) 2GB of KVA. Even the FreeBSD figure is just 3% of RAM on those machines. With the KVA being that low a percentage of the total amount of physical memory, you really have to watch carefully at all the excess fat on your data structures... This would certainly be true for the page table and pmap architecture in FreeBSD; Linux is already running into the problem that under some (common on such machines) workloads on the 16GB - 64GB sized machines the needed page tables are almost as large as the total KVA. The solution for this will probably be the use of 2MB pages for the large SHM segments and mmap()ed files. This way we can keep the flexibility of paging (needed by SAP) and bring the pagetable overhead down a factor of 512 ;) > I personally do not think that that is worth it: Nothing but violent agreement here. > The really fundamental problems with FreeBSD at this > point devolve down to some moderately easily repaired > historical artifacts in its VM architecture and allocation > techniques and policies, as well as administrative > limits for "general purpose" use being the defaults, > with no way to "autotune" based on workload. Most of > the fixes have been known in the literature since the > early and mid 1990's (though some are more recent). These aren't even that fundamental. In Linux 2.2 and 2.4 we solved most of these autotune thingies without too much impact on the code. The only major problem is that the writers of each subsystem set a too high maximum for their subsystem ... something I'm slowly getting around to fixing ;) cheers, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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?Pine.LNX.4.33.0106210917160.6263-100000>