[2.6] [PATCH] [LARGE] Rewrite/cleanup of PCI DMA mapping code

Anton Blanchard anton at samba.org
Tue Feb 10 01:47:28 EST 2004

> > - Minimum guaranteed TCE table size (128MB for 32bit slot, 256MB for
> >   64bit slot)
> Not sure I follow this one. Are you saying we need to guarantee a minimum?
> On SMP, we just carve up the space reserved by the PHB in equal chunks per
> slot, on LPAR we just use the ibm,dma-window property to size the space.

Just looking at worst case scenarios. eg how would an emulex survive
with only 256MB of TCE space.

> Yes, the behaviour here would be interesting. It'll still only be 4-page
> allocations so I don't expect any trouble. Allocations closer to 16 pages
> would be more likely to fail due to fragmentation.

Agreed. I havent seen a device that wanted to do really large allocations.
They might do large consistent allocations but thats not so bad, we can
take our time to allocate those and can in the end fail them (they are
usually during driver init).

The only other thing to keep in mind is we enable physical merging
on scatter gather lists, if we were really unlucky we could end up with
a very large element in the SG list.
> Can we blindly base this on architecture, i.e. all POWER4-based systems
> will be fine with 8MB and the other way around?

Assuming we are happy with 2GB on pre POWER4 machines we can go with
that. Then in tce table init we check the OF properties and put a limit
on the POWER4 tce table and perhaps the POWER3/RS64 one (eg on

> There's room for improvement here, but did a simple first implementation
> that will try to honor the PHB cachelines when allocating:

Yep, Im just dumping all the ideas that have come up over the last year.
I like simple and would prefer not to complicate the allocator unless we
have to.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc64-dev mailing list