Re: libata .sg_tablesize: why always dividing by 2 ?

[Mark Lord <liml@rtr.ca>]

Benjamin Herrenschmidt wrote:
> On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote:
>> Benjamin Herrenschmidt wrote:
>>>> James B.  suggests that we stick a WARN_ON() into libata to let us
>>>> know if that precondition is violated.  Sounds like an easy thing to do
>>>> for a couple of -rc cycles someday.
>>> If the block layer gives us a 32k block aligned on a 32k boundary
>>> (aligned), we have no guarantee that the iommu will not turn that into
>>> something unaligned crossing a 32k (and thus possibly a 64k) boundary.
>> ..
>>
>> Certainly, but never any worse than what the block layer gave originally.
>>
>> The important note being:  IOMMU only ever *merges*, it never *splits*.
> 
> Yes, but it will also change the address and doesn't guarantee the
> alignment.
> 
>> Which means that, by the time we split up any mis-merges again for 64K crossings,
>> we can never have more SG segments than what the block layer originally
>> fed to the IOMMU stuff.
>>
>> Or so the IOMMU and SCSI experts here at LSF'08 have assured me,
>> even after my own skeptical questioning.
> 
> I suppose so. I don't remember all of the details, but iirc, it has to
> do with crossing 64K boundaries. Some controllers can't handle it.
> 
> It's not only the _size_ of the segments, it's their alignment.
> 
> The iommu will not keep alignement beyond the page size (and even
> then... on powerpc with a 64k base page size, you may still end up with
> a 4k aligned result, but let's not go there now).
..

That's just not possible, unless the IOMMU *splits* segments.
And the IOMMU experts here say that it never does that.

-ml