Re: IOMemoryDescriptor: Jedai trick for the tortuous
Re: IOMemoryDescriptor: Jedai trick for the tortuous
- Subject: Re: IOMemoryDescriptor: Jedai trick for the tortuous
- From: Kurt Revis <email@hidden>
- Date: Mon, 7 Oct 2002 03:49:16 -0700
On Sunday, October 6, 2002, at 07:35 PM, Herbie Robinson wrote:
The game is to allocate some memory, get a list of physical ranges it
occupies, and remap them *twice* end to end.
Be aware that this trick will cause TLB thrashing on some hardware
(don't know if that applies to the PPC or not).
I'm not sure exactly what you mean by TLB thrashing, in this specific
case... can you clarify?
I just spent some quality time with the PPC manuals. It looks like it's
perfectly acceptable to have multiple page table entries pointing at
the same physical memory. Since the number of page table entries in the
TLB cache is fixed, obviously using more PTEs will mean that some of
them will get pushed out of the cache earlier.
It's unclear how much of a performance hit this is, though. I would
expect most accesses to the 2nd 'mirror' area to be at the beginning;
the end will probably never get touched. (That is, the size of each
read or write to the ring buffer is much smaller than the size of the
whole buffer.) So if the ring buffer is N pages in size, there are 2N
PTEs for it, but we expect to only use (N + a few) of them, and the
total impact on the TLB is not really increased very much.
Also, in one timeslice, my particular application will most likely not
touch *both* the 'real' and 'mirror' addresses for any physical page.
(Maybe one or the other, but not both.) Since the TLB is only useful
within one timeslice--it's full of junk when the timeslice starts--the
total number of TLB misses doesn't change at all.
(As always, I could be wrong about any of this, and welcome
corrections. I've never really looked at the PowerPC MMU before.)
In most cases, it's probably not worth it, but YMMV.
I agree that on the application level it's a fun trick, but not a big
deal. I don't know if it would be more useful in a driver, or not.
--
Kurt Revis
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.