Re: kmem_alloc replacement in Tiger
Re: kmem_alloc replacement in Tiger
- Subject: Re: kmem_alloc replacement in Tiger
- From: Andrew Gallatin <email@hidden>
- Date: Wed, 1 Feb 2006 09:40:16 -0500 (EST)
Terry Lambert writes:
>
> 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.
Here is my rational for using kmem_alloc(). My driver is cross
platform (linux, windows, solaris, freebsd, macosx) and all
allocations are done from platform independent code, which calls a
platform dependent allocator. I'm using kmem_alloc() (via
IOMallocAligned()) inside my macosx allocator. The allocator has no
idea how the memory will be used.
Practically, all large allocations are subsequently wired for DMA and
mapped into user space via platform dependent code (IOKit's memory
descriptor routines on macosx). There are some allocations which are
much smaller, which do not need to be wired.
Your comment about bouncing concerns me, especially because we wire
userspace memory for DMA so changes to our driver's memory allocator
would not guarantee all memory we need to deal with comes from the
lower 4GB. The 32-bit nature of IOKit is frustrating, because our
device is DAC capable and our older products have been for as long as
I can remember.
Please tell me that there is some way to coax a full, 64-bit DMA
address out of IOKit on a DARTless system. OS-bypass doesn't make any
sense when the DMA involves bounce buffers. It looks like
getPhysicalSegment64() will only really return a 64-bit address on a
DARTful system (where it is useless for DMA), but perhaps I'm reading
the code wrong.
Drew
_______________________________________________
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