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: Tue, 31 Jan 2006 15:39:13 -0800
On Jan 31, 2006, at 6:00 AM, Andrew Gallatin wrote:
Terry Lambert writes:
On Jan 30, 2006, at 8:06 PM, Herbert wrote:
I am trying to replace kmem_alloc with another equivalent call in
Tiger.
It was suggested that I used OSMalloc instead, but this won't work
since it does not get it's memory from the same place.
Basically, I have to allocate a huge chunk (4+ MB) for an array, so
I need basic access.
We are currently looking at IOBufferMemory etc., but we're not sure
if it will work.
Has anyone had to deal with this?
Unless you are creating your own submap, the memory all comes from
the
same place: kernel_map and the underlying implementation is all the
same code.
At least for non pageable memory, OSMalloc will allocate memory using
kalloc. The kalloc() routine uses the kalloc_map submap, which is
only 16MB in size.
Other people can correct me, if I make a mistake here, but...
This is on purpose, to discourage large non-pageable allocations -
allocations requiring non-movable commitments of physical RAM.
Predominantly, people should allocate pageable pages; pageable pages
have kernel virtual address mappings, but no backing physical pages
initially associated with them until they are needed.
You can explicitly associate physical pages with these by explicitly
calling appropriate vm_ routines (documented on developer.apple.com;
you just have to look for them), and there are IOKit calls that will
wire them down for the duration of I/O operations. The only case
where this is less useful is if a large physically contiguous region
is required because we are talking about a device driver incapable of
scatter/gather operations, or for which such operations result in a
large performance penalty on the flip side (e.g. video capture at
close to hardware clock limits, etc.).
As you point out in another posting, you can also use IOMallocAligned
(); but if he has a driver like this, he probably actually wants
IOMallocContiguous(); the latter would be the best bet for the scatter/
gather restricted hardware, and the pageable nature of the aligned
memory in the OSMalloc() case being the only issue, probably means he
doesn't need IOMallocAligned().
In general, if the memory is not going to be a DMA target, then it
should not matter what the backing physical memory is, since you
aren't communicating the physical memory address to a device driver.
In other words, pageable memory should be OK for most non-driver usage.
Even if you *are* talking to a device driver, though, you should use
IOKit routines to do it. In the case of a G5 or other large physical
memory system, physical memory above 4G will either need to be
remapped via moving the DART window in the memory controller, or by
bouncing, if you didn't use an IOKit routine to allocate the memory in
the DART window or below 4G to avoid needing the bounce.
Since Herb was talking about using the memory for a large array, I
recommended the API that I'd normally tell people to use for that
usage. If this array was actually a driver DMA target, well, then one
of the other options is probably a better bet.
-- 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