Jeff Garzik wrote:
Mark Lord wrote:
But (as I replied to myself earlier), I think it is a non issue,
because the IOMMU merging cannot produce more SG entries than
there were originally. It may produce less, and the driver may then
end up splitting them apart again, but it will never exceed what
the block layer permitted in the first place.
That says nothing about the boundaries upon which the IOMMU layer will
or will not merge. Without the fix, the problem case happens when (for
example) the IOMMU output produces sg_tablesize segments, but some of
those segments cross a 64k boundary and need to be split.
Yes, but the merging happens *after* the block layer has already
guaranteed an sg list that respects what the driver told it.
So worst case, the IOMMU merges the entire sg list into a single
multi-megabyte segment, and then the driver's fill_sg() function
splits it all apart again while making up it's PRD list.
Even in that worst case, the number of segments for the PRD list
will *always* be less than or equal to the size of the original
block layer sg list.
So no need for hocus-pocus divide by 2.
Good thing, too, because "divide by 2" would also fail
if the above stuff were not true.
Think about it some more.
Jens, you know more about this stuff than most folks:
What am I missing?
Thanks.
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
