mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Olivier Galibert <galibert@pobox.com>,
	"Hack inc." <linux-kernel@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: Can a non-sg scsi write command be more than PAGE_SIZE length?
Date: Tue, 19 Apr 2005 09:14:33 -0500	[thread overview]
Message-ID: <1113920073.4998.9.camel@mulgrave> (raw)
In-Reply-To: <20050419092926.GA9785@infradead.org>

On Tue, 2005-04-19 at 10:29 +0100, Christoph Hellwig wrote:
> Good question actually.  I know XFS does passed vmalloc'ed memory down
> the block I/O path, but that's as a scatter/gather request.  All non-s/g
> request should be contingous I think.
> 
> We really need to write down the rules about what memory can be passed
> down the block I/O path - XFS for example sends kmalloced memory down
> which all the iSCSI implementations don't like at all.

We have two rules and two cases in every driver: sg and non-sg.  (i.e.
use_sg == 0)  this is where we do the distinction between dma_map_sg and
dma_map_single.

If someone wants a project, it should be possible to eject our non-sg
path.  This would mean that all requests go as sg through the block
layer.  The advantages would be

1) internally we would no longer care about kmalloc vs vmalloc memory
2) we wouldn't need to know the gfp flag when allocating internal
requests (block would bounce for us if necessary) thus we could kill the
scsi isa dma flag
3) We could strip the special casing out of every driver ...
4) it should simplify the I/O traversal paths

James



      reply	other threads:[~2005-04-19 14:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-19  8:47 Olivier Galibert
2005-04-19  8:50 ` Christoph Hellwig
2005-04-19  9:24   ` Olivier Galibert
2005-04-19  9:29     ` Christoph Hellwig
2005-04-19 14:14       ` James Bottomley [this message]

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=1113920073.4998.9.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=galibert@pobox.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®