On 06/07/2012 02:12 AM, Duncan wrote:
<SNIP>
Meanwhile, your above isn't quite right either.
Part of it appears to have been left out. But, the point was how to
access all of the 4 GiB of physical memory.
32-bit kernels can only
address 4 gigs at a time, and normally that's split between user and
kernel address space,
I thought that the standard allocation was 1 GiB for system and 3 GiB
for user.
but there's a 4-gig/4-gig option with a bit of an
extra performance hit when switching between user mode and kernel mode,
and even an upto 64-gig option, using hardware pni mode paging to address
a 4 gig movable address-window on the larger 64-gig total frame.
Obviously this comes with a bit more of a performance hit, but moving a 4-
gig address window on 64-gig of memory is still way faster than waiting
on a slow disk.
We take as a given that a process can only address 4 GiBs with 32 bits.
However it is also a given that hardware does not need to have that
much physical memory. I fully understand only the Motorola 32K and the
Intel Pentium hardware but I presume that all hardware memory management
is similar. In both cases the memory management hardware allows each
process to have a virtual address space of 4 GiBs. I have always been
disappointed that Linux has diverged from actual UNIX in this regard
with the use of a 'flat' memory space. But, then UNIX will only run on
systems with hardware memory management and Linux runs on my Television
set (yes my Sony 42" flat screen runs the Linux OS). I have always
thought that the solution to this problem would be to do both -- support
virtual memory (as opposed to flat) when there is memory management
hardware and use flat memory when there is not MM hardware.
The first step in this would be to use the fact that the MM hardware
knows when the system is running in user or system mode and on Pentium
type hardware there can be one memory allocation table for the system
space and one for user space with switching between them being automatic
if a software interrupt is used to switch with the only other overhead
being cache misses.
The result would be a 4 GiB space for system space and 4 GiBs for user
space. However, this does not solve the problem of not being able to
address the whole 4 GiB of physical memory.
That is why I wondered if it would work OK to only have only the OS use
64 bits. This should mean that the memory allocation tables would use
64 bit addresses which would allow access to the whole 4 Gib of physical
memory (or I suppose more if the system had more) -- specifically the
missing chunk that is mapped to higher than 4-GiB.
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
