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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote:
> Mark Lord wrote:
> > Jeff,
> > 
> > We had a discussion here today about IOMMUs,
> > and they *never* split sg list entries -- they only ever *merge*.
> > 
> > And this happens only after the block layer has
> > already done merging while respecting q->seg_boundary_mask.
> > 
> > So worst case, the IOMMU may merge everything, and then in
> > libata we unmerge them again.  But the end result can never
> > exceed the max_sg_entries limit enforced by the block layer.
> 
> <shrug>  Early experience said otherwise.  The split in foo_fill_sg() 
> and resulting sg_tablesize reduction were both needed to successfully 
> transfer data, when Ben H originally did the work.
> 
> If Ben H and everyone on the arch side agrees with the above analysis, I 
> would be quite happy to remove all those "/ 2".

The split wasn't done by the iommu. The split was done by the IDE code
itself to handle the stupid 64k crossing thingy. If it's done
differently now, it might be possible to remove it, I haven't looked.

Cheers,
Ben.


-
To unsubscribe from this list: 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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux