From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: libata .sg_tablesize: why always dividing by 2 ? Date: Tue, 26 Feb 2008 00:43:55 -0500 Message-ID: <47C3A71B.2070705@rtr.ca> References: <47C3572D.1060904@rtr.ca> <47C35A3B.8080604@pobox.com> <1203987277.15052.68.camel@pasglop> <47C36D64.6010001@rtr.ca> <47C36EC3.4080708@rtr.ca> <1203994454.15052.83.camel@pasglop> <47C397C4.2090309@rtr.ca> <1204003805.15052.112.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from rtr.ca ([76.10.145.34]:3572 "EHLO mail.rtr.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751412AbYBZFlB (ORCPT ); Tue, 26 Feb 2008 00:41:01 -0500 In-Reply-To: <1204003805.15052.112.camel@pasglop> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: benh@kernel.crashing.org Cc: Jeff Garzik , Tejun Heo , Alan Cox , James Bottomley , IDE/ATA development list 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