[kde-linux] Very ugly image in X root window.

[James Tyrer]

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