mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Salyzyn, Mark" <mark_salyzyn@adaptec.com>
To: "Alan Cox" <alan@redhat.com>,
	"Christoph Hellwig" <hch@infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-scsi@vger.kernel.org>
Subject: RE: PATCH: Further aacraid work
Date: Thu, 17 Jun 2004 08:53:36 -0400	[thread overview]
Message-ID: <547AF3BD0F3F0B4CBDC379BAC7E4189FD23FF9@otce2k03.adaptec.com> (raw)

Using the 32 bit dma descriptors was used to optimize the transfer size
and performance. There is a small performance hit by switching to a
resultant larger FIB (adapter command packet) with 64 bit SG elements,
and an accompanied reduced limit on the number of total SG elements
available. Since the scsi layer has a propensity to provide sequentially
decreasing pages (sequentially increasing would permit coalescing of SG
elements) for the SG elements, we find that there is an average SG
element size of 4K.

The performance hit is up to 15% when the request has to be split to fit
into the available SG element slots.

An increase in performance of the scsi layer could occur if the
allocator provided sequentially increasing pages to permit a larger SG
element to be sent down to the adapter, and thus a larger request down
to the adapter.

I *must* admit that the driver functions perfectly in other systems with
more than 4G of memory; however we *are* having troubles specifically
with AMD64 systems with more than 4G of memory in 2.6 kernels (the issue
does not occur on 2.4 kernels). I have yet to investigate why this
specific problem exists.

One would expect that if we erroneously got the memory model wrong (ie,
<4GB of memory, one slice at 0-2G, another slice at 4G-6G) that the 32
dma limit would protect us from functional problems in this delicate
area but with a performance hit resulting from the scsi layer providing
bounce buffers. Ideally we would like to have a mechanism to know if the
DMAable area is limited to a 32 bit address space in order to take
advantage of the more efficient FIB utilization.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Alan Cox
Sent: Wednesday, June 16, 2004 6:06 PM
To: Christoph Hellwig; Alan Cox; linux-kernel@vger.kernel.org;
linux-scsi@vger.kernel.org
Subject: Re: PATCH: Further aacraid work

On Wed, Jun 16, 2004 at 10:58:34PM +0100, Christoph Hellwig wrote:
> Yikes.  This looked like they usual use 32bit dma descriptors if not
> enough memory hacks to me.  If aacraid is that royally fucked we
should
> probably add CONFIG_X86 to it.

Its working on x86-32, x86-64 and I believe (Mark can confirm this)
IA-64.
I'm fairly sure there are some platforms that aren't going to fit the
hardware's view of the world which seems to be

0[DMAable area..................]defined limit   [4Gb+.. PAE mode on
some]

The later cards also have a 2Gb limit for the ring buffers, but not for
the
I/O you want to target


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2004-06-17 12:53 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-17 12:53 Salyzyn, Mark [this message]
2004-06-17 13:07 ` Matthew Wilcox
2004-06-17 13:19   ` Christoph Hellwig
2004-06-17 13:55   ` James Bottomley
2004-06-17 13:32 ` Christoph Hellwig
2004-06-17 14:02 ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2004-06-29 20:55 Salyzyn, Mark
2004-06-29 23:22 ` Byron Stanoszek
2004-06-30 19:52 ` Byron Stanoszek
2004-06-30 19:59   ` Dario
2004-06-29 19:27 Salyzyn, Mark
2004-06-29 20:20 ` Byron Stanoszek
2004-06-29 20:42 ` Alan Cox
2004-06-29 18:53 Salyzyn, Mark
2004-06-29 19:03 ` Byron Stanoszek
2004-06-28 13:17 Salyzyn, Mark
2004-06-18 20:53 Salyzyn, Mark
     [not found] <286GI-5y3-11@gated-at.bofh.it>
     [not found] ` <286Qp-5EU-19@gated-at.bofh.it>
2004-06-17 19:10   ` Andi Kleen
2004-06-17 20:54     ` Alan Cox
2004-06-17 21:13       ` James Bottomley
2004-06-17 21:25       ` Andi Kleen
2004-06-18 15:19         ` Benjamin Herrenschmidt
2004-06-18  5:57       ` Jeff Garzik
2004-06-18 14:07         ` James Bottomley
2004-06-18 15:17     ` Benjamin Herrenschmidt
2004-06-17 17:54 Salyzyn, Mark
2004-06-17 20:38 ` Alan Cox
2004-06-17 20:48   ` William Lee Irwin III
2004-06-17 20:56     ` James Bottomley
2004-06-18 15:05     ` William Lee Irwin III
2004-06-18 20:32       ` William Lee Irwin III
2004-06-27 17:33         ` James Bottomley
2004-06-17 14:39 Salyzyn, Mark
2004-06-17 14:55 ` James Bottomley
2004-06-17 14:58   ` Alan Cox
2004-06-17 15:15     ` Arjan van de Ven
2004-06-17 19:16       ` James Bottomley
2004-06-17 16:32   ` Clay Haapala
2004-06-17 16:37     ` James Bottomley
2004-06-17 16:46     ` Alan Cox
2004-06-17 15:11 ` Anton Blanchard
2004-06-16 21:04 Alan Cox
2004-06-16 21:33 ` Christoph Hellwig
2004-06-16 21:40   ` Alan Cox
2004-06-16 21:42     ` Christoph Hellwig
2004-06-16 21:48       ` Alan Cox
2004-06-16 21:58         ` Christoph Hellwig
2004-06-16 22:06           ` Alan Cox
2004-06-29 17:48 ` Byron Stanoszek
2004-06-29 18:27   ` Mark Haverkamp
2004-06-29 18:37   ` Alan Cox
2004-06-30  2:02 ` bm
2004-06-30 16:07   ` Alan Cox

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=547AF3BD0F3F0B4CBDC379BAC7E4189FD23FF9@otce2k03.adaptec.com \
    --to=mark_salyzyn@adaptec.com \
    --cc=alan@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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

all inboxes | Powered by JetHome®