linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: benh@kernel.crashing.org
Cc: Jeff Garzik <jgarzik@pobox.com>, Tejun Heo <htejun@gmail.com>,
	Alan Cox <alan@redhat.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: libata .sg_tablesize: why always dividing by 2 ?
Date: Mon, 25 Feb 2008 23:38:28 -0500	[thread overview]
Message-ID: <47C397C4.2090309@rtr.ca> (raw)
In-Reply-To: <1203994454.15052.83.camel@pasglop>

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

  reply	other threads:[~2008-02-26  4:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26  0:02 libata .sg_tablesize: why always dividing by 2 ? Mark Lord
2008-02-26  0:15 ` Jeff Garzik
2008-02-26  0:27   ` Mark Lord
2008-02-26  0:54   ` Benjamin Herrenschmidt
2008-02-26  1:37     ` Mark Lord
2008-02-26  1:43       ` Mark Lord
2008-02-26  2:54         ` Benjamin Herrenschmidt
2008-02-26  4:38           ` Mark Lord [this message]
2008-02-26  5:30             ` Benjamin Herrenschmidt
2008-02-26  5:43               ` Mark Lord
2008-02-26  5:47                 ` Benjamin Herrenschmidt
2008-02-26 16:09                   ` James Bottomley
2008-02-26 21:43                     ` Benjamin Herrenschmidt
2008-02-26 16:25                   ` Mark Lord
2008-02-26 16:51                     ` Mark Lord
2008-02-26 21:50                       ` Benjamin Herrenschmidt
2008-02-26 21:56                         ` James Bottomley
2008-02-26 22:30                           ` Benjamin Herrenschmidt
2008-02-26 23:16                             ` Benjamin Herrenschmidt
2008-02-26 21:43                     ` Benjamin Herrenschmidt
2008-02-26 23:07                       ` Alan Cox
2008-02-26 23:19                         ` Benjamin Herrenschmidt
2008-02-28  7:36                           ` FUJITA Tomonori
2008-02-28  7:44                             ` Benjamin Herrenschmidt
2008-02-26  2:52       ` Benjamin Herrenschmidt
2008-02-26  0:22 ` Jeff Garzik
2008-02-26  0:28   ` Mark Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47C397C4.2090309@rtr.ca \
    --to=liml@rtr.ca \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=alan@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=htejun@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).