site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jan 31, 2006, at 6:00 AM, Andrew Gallatin 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. 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... -- 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... Terry Lambert writes: On Jan 30, 2006, at 8:06 PM, Herbert wrote: 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. 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. This email sent to site_archiver@lists.apple.com