From owner-freebsd-hackers Thu Aug 2 22: 8:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 3BC6537B401; Thu, 2 Aug 2001 22:08:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.104.136.Dial1.SanJose1.Level3.net [209.244.104.136]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA20649; Thu, 2 Aug 2001 22:08:16 -0700 (PDT) Message-ID: <3B6A31E8.836122DA@mindspring.com> Date: Thu, 02 Aug 2001 22:08:56 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: freebsd-hackers@FreeBSD.org, craig Subject: Re: How to visit physical memory above 4G? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > Err. hang on. This has zero to do with segmentation. Zip, nada. > PAE is completely in the paging side of things. No matter what > fun games you play with segmentation, you still end up with a > 32-bit linear address that gets handed off to the paging translations. > PAE just allows you to use more backing store across multiple > processes, but you are still stuck with a 4gb virtual address > space for processes. (Including KVM) IMO, the 4 bit selector "register" is the moral equivalent of a segment register. Personally, I think it's much less useful to run the kernel out of KVA space, than it is to have more memory available to the kernel for things like mbufs, so I'm not really very interested in trying to raise the per process address space limits this way. You could actually get 4G for the kernel and 4G for processes using this, but you would only need two "segments" to make this happen; mapping the other stuff at the same time makes little sense: you just map a window on it to implement region overlays for user or kernel data paging. Given the compiler tools we have, this still limits you to using only 4G in a given VA space, unless you did something evil, like add "HLOCK/HUNLOCK", etc.. > > But to directly answer your question: by rewriting much of the > > low core virtual memory and page mapping handling code to know > > about segmentation. > > No, to rewrite said code to handle a different type of page table > structure. Virtual table structure/segements: same difference: I'm now wdoing in software what I bought hardware to get away from having to do in software. Given the vastly simplified page management in Linux, I could see how there wouldn't really be a big performance loss over the way Linux does things without this, so it might be OK, so long as there were no shared memory regions, semaphores, etc.. That really makes it pretty useless. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message