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>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: libata .sg_tablesize: why always dividing by 2 ?
Date: Wed, 27 Feb 2008 09:30:01 +1100 [thread overview]
Message-ID: <1204065001.15052.177.camel@pasglop> (raw)
In-Reply-To: <1204063001.3254.96.camel@localhost.localdomain>
On Tue, 2008-02-26 at 13:56 -0800, James Bottomley wrote:
> > Our iommu can use smaller than PAGE_SIZE allocations when PAGE_SIZE is
> > 64k (it can use 4k), and that helps a lot with networking to avoid
> > filling up pSeries small iommu's too fast. Unfortunately, that meant we
> > used to not even get PAGE_SIZE alignment for some cases. The workaround
> > fixes that but does not provide natural size alignment.
> >
> > If we were to provide size based alignment of sg requests, fragmentation
> > would become so bad we would basically end up failing a large amount of
> > iommu allocations on servers.
>
> Ben, he just quoted the wrong patch ... that was the segment length
> limit patch. The boundary alignment patch is this one:
>
> fb3475e9b6bfa666107512fbd6006c26014f04b8
>
> And it does alter the ppc iommu to respect the dma_boundary, so all of
> the mechanics for removing the ppc special casing in libata/ide is
> upstream.
And the fact that this will totally blow fragmentation through the roof
and cause half of the dma-map requests to fail on machines with small
iommu has been totally ignored I suppose ?
Ben.
next prev parent reply other threads:[~2008-02-26 22:37 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
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 [this message]
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=1204065001.15052.177.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alan@redhat.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.