Re: kmem_alloc replacement in Tiger
Re: kmem_alloc replacement in Tiger
- Subject: Re: kmem_alloc replacement in Tiger
- From: Terry Lambert <email@hidden>
- Date: Wed, 1 Feb 2006 15:11:50 -0800
On Feb 1, 2006, at 2:38 PM, Nikita Danilov wrote:
Terry Lambert writes:
[...]
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden