Re: [bug #17346] GNU mach can't handle 4GB memory

[Constantine Kousoulos]

Hello,

All the above solutions aim to make Mach unaware of any memory 
above 1 GB. Isn't it possible to utilise all the memory? I will 
explain myself.

Why don't we make Mach's kernel address space larger so that the 
whole memory can fit inside it? Mach's virtual address space is 4 
GB big according to this entry in gnumach/i386/i386/vm_param.h: 
#define VM_MAX_KERNEL_ADDRESS	((vm_offset_t) 0x40000000)).
Why not enlarge kernel space virtual memory and decrease user 
space virtual memory in order to directly map the whole physical 
memory in kernel address space.

For example, if we want Mach to directly map aproximately 2 GB we 
would do the following:

diff -u gnumach/i386/i386/vm_param.h suggested_vm_param.h
--- ../gnumach/i386/i386/vm_param.h	2001-04-05 09:39:20.000000000 
+0300
+++ suggested_vm_param.h        2006-11-20 14:57:56.000000000 +0200
@@ -26,14 +26,14 @@
 /* XXX use xu/vm_param.h */
 #include <mach/vm_param.h>

-/* The kernel address space is 1GB, starting at virtual address 
0.  */
+/* The kernel address space is aproximately 2GB, starting at 
virtual address 0.  */
 #define VM_MIN_KERNEL_ADDRESS  ((vm_offset_t) 0x00000000)
-#define VM_MAX_KERNEL_ADDRESS  ((vm_offset_t) 0x40000000)
+#define VM_MAX_KERNEL_ADDRESS  ((vm_offset_t) 0x80000000)

 /* The kernel virtual address space is actually located
    at high linear addresses.
    This is the kernel address range in linear addresses.  */
-#define LINEAR_MIN_KERNEL_ADDRESS      ((vm_offset_t) 0xc0000000)
+#define LINEAR_MIN_KERNEL_ADDRESS      ((vm_offset_t) 0x80000000)
 #define LINEAR_MAX_KERNEL_ADDRESS      ((vm_offset_t) 0xffffffff)

 #define KERNEL_STACK_SIZE      (1*I386_PGBYTES)

Of course, we would also have to reserve some memory for virtual 
mappings as it is currently done. This is why i said i mapped 
_aproximately_ 2 GB. Actually, it would be a little less.

We could also do the same for 3 GB of memory, thus leaving only 1 
GB for user space. It is obvious that we can't do the same for 4 
GB of memory because there wouldn't be any virtual memory left.

So, we could add some configure switches to enable a 1-3 or a 2-2 
or a 3-1 memory ratio, depending on the desired setup. In addition 
to the above, we would also have to use the already proposed 
solution to cut off some memory that Mach can't handle. For 
example, if someone has 4 GB of memory and has setup the kernel 
for a 3-1 ratio (that is 3 Gigs in kernel space), there would have 
to be something like this in model_dep.c:

phys_first_addr = 0;
#ifdef CONFIG_3_TO_1_MEM_RATIO
if (boot_info.mem_upper>0x200000)
        phys_last_addr = 0x200000
else
        phys_last_addr = 0x100000 + (boot_info.mem_upper * 0x400);

/* Reserve 1/16 of the memory address space for virtual mappings.
 * Yes, this loses memory.  Blame i386.  */
if (phys_last_addr > (VM_MAX_KERNEL_ADDRESS / 16) * 15)
        phys_last_addr = (VM_MAX_KERNEL_ADDRESS / 16) * 15;
#endif

avail_remaining
	  = phys_last_addr - (0x100000 - (boot_info.mem_lower * 0x400) - 
0x1000);
printf("AT386 boot: physical memory from 0x%x to 0x%x\n",
               phys_first_addr, phys_last_addr);

phys_first_addr = round_page(phys_first_addr);
phys_last_addr = trunc_page(phys_last_addr);


Is this solution sound? I haven't tested it because i don't have a 
computer with more than 1 GB of memory. I also don't know how a 
decrease in user space virtual memory will affect the performance 
of GNU/Hurd. Please provide feedback.


Thanks,
Constantine