site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Feb 1, 2006, at 2:38 PM, Nikita Danilov wrote: Terry Lambert writes: [...] -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Likewise, at least with FreeBSD's unified VM and buffer cache, and in NetBSD's case, their UVM implementation, and Windows, it's also likely better to avoid the possibility of fragmentation of the kernel virtual address map, even if it's a full 64 bits. The main issue is the number of pmap entries needed to support that large an address space grows as the address space becomes fragmented, even if the amount of available physical memory is relatively small. I believe this will also be a problem on Linux, unless something happened very recently to change things there; it may or may not be a problem on Solaris, In overwhelming majority of cases Linux uses 1:1 mapping of physical to virtual memory in the kernel mode, and kernel `pmap' is modified quite rarely. All major memory consumers (file system, anonymous memory, slab allocator) work in 1:1 mode. So it's still an issue because of the mapping into and out of the user process address spaces taking pmap entries. I was aware that it would be a problem for Linux the last time I read the sources, but it's been a while since I've followed the LKML closely enough to speak authoritatively on the answer. This email sent to site_archiver@lists.apple.com