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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2008-02-26 at 16:47 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
> > > 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.
> 
> It is totally possible, and I know as wrote part of the powerpc iommu
> code :-)
> 
> The iommu code makes no guarantee vs. preserving the alignment of a
> segment, at least not below PAGE_SIZE.

It's supposed to, precisely to forestall this case.  The alignment
guarantees of the parisc iommu code are sg length aligned up to a fixed
maximum (128k on 32 bit and 256k on 64 bit because of the way the
allocator works).   However, tomo's code is fixing this, so it shouldn't
be a problem much longer.

James