On Tue, Mar 21 2006, Mark Lord wrote: > 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? Seems to me that your reasoning is correct. It's a fact that the original block mapped sg lists satisfies all requirements of the device driver and/or hardware, otherwise would be a bug. The iommu may go nuts of course, but logically that new sg list should be choppable into the same requirements. It would be much nicer if the iommu actually had some more knowledge, ideally the same requirements that the block layer is faced with. No driver should have to check the mapped sg list. -- Jens Axboe - : 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
