lkml.org 
[lkml]   [2004]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [ppc64] watch IOMMU virtual merging

> This is a rather painful state of affairs. I'm not convinced external
> fragmentation in the IOMMU address space is insurmountable as the
> physically contiguous segments can (in principle; the mechanics of
> ramming this through the IO subsystem are another matter entirely) be
> IO-mapped in a bus-discontiguous fashion.

Yep they can, but if the SG list has been sized to fit after physically
merging then we have a problem when we later on want to split it. If the
architecture had more control over the merging process we could do a
better job here.

> I'm not familiar with the TCE space regions; could you describe or
> point to documentation for the semantics there?

Think of it as a mapping from PCI to host memory, a window of at least
128MB and up to 3GB. You get to carve it up on a page granularity as you
like, we currently create 2 regions, a small allocation region and a
large one (above 15 pages). The aim is to (hopefully) avoid
fragmentation in the large allocation region.

> My first thought is to artificially limit the amount of physical
> merging (hopefully to some nonzero amount instead of disabling it
> entirely) allowed to take place in order to allow for better virtual
> merging.

Removing the large allocation region should also fix our problems. I
should test that to verify its our problem.

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.080 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site