From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: libata .sg_tablesize: why always dividing by 2 ? Date: Mon, 25 Feb 2008 23:38:28 -0500 Message-ID: <47C397C4.2090309@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> 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]:3993 "EHLO mail.rtr.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750709AbYBZEfg (ORCPT ); Mon, 25 Feb 2008 23:35:36 -0500 In-Reply-To: <1203994454.15052.83.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: >> 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*. 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. Cheers