From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Mark Lord <liml@rtr.ca>, Jeff Garzik <jgarzik@pobox.com>,
Tejun Heo <htejun@gmail.com>, Alan Cox <alan@redhat.com>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: libata .sg_tablesize: why always dividing by 2 ?
Date: Wed, 27 Feb 2008 08:43:14 +1100 [thread overview]
Message-ID: <1204062194.15052.155.camel@pasglop> (raw)
In-Reply-To: <1204042187.3254.70.camel@localhost.localdomain>
On Tue, 2008-02-26 at 08:09 -0800, James Bottomley wrote:
> > 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.
It will be. If we start enforcing that alignment, pSeries machines will
continuously run out of iommu space when the BIO starts handing out
large chunks.
Not acceptable for us. I suspect x86_64 will have a similar problem as,
afaik, the IOMMU space is very scarce there.
Can you guys stop designing the whole IO layer around PA-RISC ?
Ben.
next prev parent reply other threads:[~2008-02-26 22:04 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
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 [this message]
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=1204062194.15052.155.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alan@redhat.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=liml@rtr.ca \
--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).