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
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
