Date: Fri, 03 Aug 2001 22:57:00 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Rik van Riel <riel@conectiva.com.br> Cc: Julian Elischer <julian@elischer.org>, craig <craiglei@pasia.com.cn>, freebsd-hackers@FreeBSD.ORG Subject: Re: How to visit physical memory above 4G? Message-ID: <3B6B8EAC.B4EBD5E8@mindspring.com> References: <Pine.LNX.4.33L.0108040235500.2526-100000@imladris.rielhome.conectiva>
next in thread | previous in thread | raw e-mail | index | archive | help
Rik van Riel wrote: > > This is a trivial implementation. I'm not very impressed. > > > Personally, I'm not interested in a huge user space, > > Maybe not you, but I bet the database and scientific > computing people will be interested in having 64 GB > memory support in this simple way. You mean 4G, of course, since the process address space remains limites to 32 bits... > > Fully populating both the transmit and receive windows for > > 1M connections is 32G of RAM, right there... and it better > > be kernel RAM, or you're screwed. > > Well, you _could_ store this memory in "files", which > get mapped and unmapped by the same code the filesystem > code uses to access file data in non-kernel-mapped RAM. > > *runs like hell* That's the entire problem: it has to be performant, or I'm just not interested in it. Using the memory as a software L3 would make a lot more sense to me... a 3G user space is pretty useless, from my point of view, and I'd much rather spend the space on the kernel. Cutting that to 2G/2G might be OK, with 1G in the user used for mapping regions in and out. You are still limited to how much RAM you have, but at least you aren't shooting yourself in the foot trying to make it work. You still haven't told me what Linux does for 2x4G processes and a 1G kernel with "only" 8G of physical RAM. I rather suspect that as soon as your usage exceeds real memory, it all goes to hell very quickly, since your L1 and L2 caches are effectively disabled by the frequent reloading of CR3 and CR4 on context switches... -- Terry 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?3B6B8EAC.B4EBD5E8>