All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Clay Haapala <chaapala@cisco.com>
Cc: "Salyzyn, Mark" <mark_salyzyn@adaptec.com>,
	Christoph Hellwig <hch@infradead.org>, Alan Cox <alan@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: PATCH: Further aacraid work
Date: 17 Jun 2004 11:37:04 -0500	[thread overview]
Message-ID: <1087490225.2210.48.camel@mulgrave> (raw)
In-Reply-To: <yqujzn72uov6.fsf@chaapala-lnx2.cisco.com>

On Thu, 2004-06-17 at 11:32, Clay Haapala wrote:
> Today's scatterlists already handle entries with a size greater than
> MMU pagelength, even on x86, right?  We have seen it in iSCSI driver
> testing, though it is not the usual case.  crypto/digests.c:update()
> function was recently patched to handle the case and properly kmap()
> the additional memory represented by the sg entry.

Yes.  The bio layer does two operations on sg elements: clustering and
virtual merging.  Clustering tries to coalesce two adjacent I/O pages
that also happen to be adjacent in memory physical space.  virtual
merging uses an IOMMU to place non-physically-adjacent pages at adjacent
locations in bus physical space.

> So, on regular x86 this is a matter of convenience/timing, and the
> page assignments will tend toward, but not always be, random 1-page
> entries as the system is used.

That's what the jury is out on, I think.  The question is could we
improve the chances of clustering by altering the way the vm allocator
works.

James



  reply	other threads:[~2004-06-17 16:38 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-17 14:39 PATCH: Further aacraid work Salyzyn, Mark
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 [this message]
2004-06-17 16:46     ` Alan Cox
2004-06-17 15:11 ` Anton Blanchard
  -- 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
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 12:53 Salyzyn, Mark
2004-06-17 12:53 ` Salyzyn, Mark
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
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=1087490225.2210.48.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=alan@redhat.com \
    --cc=chaapala@cisco.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mark_salyzyn@adaptec.com \
    /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.