Hi,
I reported spurious zalloc failures in the past. Roland advised me to get
more data about what objects in the kernel consume memory. This still has
to be done, and there is not much use of guesing around.
However, in my studies of the pmap.c code to implement I/O perm bitmaps for
SMP machines, I noticed this in i386/intel/pmap.c:
/*
* Range of kernel virtual addresses available for kernel memory mapping.
* Does not include the virtual addresses used to map physical memory 1-1.
* Initialized by pmap_bootstrap.
*/
vm_offset_t kernel_virtual_start;
vm_offset_t kernel_virtual_end;
/* XXX stupid fixed limit - get rid */
vm_size_t morevm = 40 * 1024 * 1024; /* VM space for kernel map */
pmap_bootstrap()
...
/*
* Determine the kernel virtual address range.
* It starts at the end of the physical memory
* mapped into the kernel address space,
* and extends to a stupid arbitrary limit beyond that.
*/
kernel_virtual_start = phys_last_addr;
kernel_virtual_end = phys_last_addr + morevm;
And that's it. It seems that whatever memory the system has, only 40 MB are
ever used for the kernel's virtual memory address space.
Now, I am not exactly sure where the kernel uses physically mapped memory,
and where it uses virtually mapped memory. It seems to me that only the
initial objects like meta information about the zones, and the kernel
virtual address pagemap itself are mapped physically, but normal zones are
taken from the virtual address space (via kmem_alloc_pageable in zalloc.c or
kmem_suballoc in kalloc.c).
40 MB might very well have been a lot at the time the file was written.
Probably the highest amount of RAM + paging space you could provide. As of
today, this is not true anymore. Nevertheless, 40 MB of kernel objects seems
pretty much to me, so maybe this is not related. Definitely more debug info
is needed, but some insight on what this limit might cause would be
appreciated (and it should be fixed of course).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
