[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Constantine Kousoulos
Subject: Re: [bug #17346] GNU mach can't handle 4GB memory
Date: Mon, 20 Nov 2006 16:15:53 +0200
User-agent: Icedove (X11/20061013)


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;
if (boot_info.mem_upper>0x200000)
        phys_last_addr = 0x200000
        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;

= 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]