All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	Andi Kleen <ak@suse.de>,
	linux-scsi@vger.kernel.org, Christoph Lameter <clameter@sgi.com>
Subject: Re: GFP_DMA use in SCSI midlayer
Date: Mon, 02 Oct 2006 13:51:25 -0500	[thread overview]
Message-ID: <45215FAD.3080109@cs.wisc.edu> (raw)
In-Reply-To: <1159814616.2945.7.camel@madmax>

Mike Christie wrote:
> On Sun, 2006-10-01 at 15:40 -0500, James Bottomley wrote:
>> On Sun, 2006-10-01 at 22:13 +0200, Andi Kleen wrote:
>>> GFP_DMA in general is deprecated and should be replaced by appropiate
>>> dma_alloc_coherent()
>> Um, no it shouldn't.
>>
>> All of the places where we use GFP_DMA are because we might be
>> addressing an ISA card or other strange mask limited card (gated usually
>> by unchecked_isa_dma).  However, what is wanted in every case is
>> ordinary memory, not coherent memory.  They can't simply be replaced
>> with dma_alloc_coherent because
>>
>> a) it will waste memory for platforms that only do it in page size
>> multiples
>> b) It will fail on platforms that can't do it at all.
>>
>> Coherent memory is really only for device drivers to use in mailboxes
>> and shared ring buffers.
>>
>>> or similar.  And I can't imagine any modern systems still need them, and for 
>>> the few still non CONFIG_BROKEN ISA drivers maybe some other way can be found?
>>> And do they really require the mid layer data structures to be GFP_DMA too?
>> Well, it's the "or similar" that's still the problem.  All they need is
>> ordinary memory which respects the device mask (then I can get rid of
>> the unchecked_isa_dma flag as well).
>>
>> One could argue, I suppose, that when we get every SCSI path to go via
>> sg, then the block layer will bounce this for us, and we don't need to
>> worry at all.
> 
> 
> I think we might just need the blk_map_kern users now. For the async

Oops, I just meant for the ULDs, scsi-ml, and block layer drivers. I did
not look at if/when the LLDs inject commands directly to their queuecommand.

> execute I added the bounce code already and the block SG_IO has it
> atleady. I think the blk_map_kern bounce code got dropped because we
> thought the correct gfp_t would be passed in. But I think all we need is
> the patch below and all the paths are take care of. The patch is not
> tested. Patch was made against scsi-misc.
> 
> The last place that is sending non sg commands may just be md/dm-emc.c
> but that is is just waiting on alasdair to take some patches that fix
> that and a bunch of junk in there including adding bounce support. If
> the patch below is ok though and dm-emc finally gets converted then it
> will have sg and bonce buffer support.
> 
> 
> 
> Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
> 
> diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
> index 9c3a06b..e58b43a 100644
> --- a/block/ll_rw_blk.c
> +++ b/block/ll_rw_blk.c
> @@ -2533,6 +2533,7 @@ int blk_rq_map_kern(request_queue_t *q, 
>  	rq->bio = rq->biotail = bio;
>  	blk_rq_bio_prep(q, rq, bio);
>  
> +	blk_queue_bounce(q, &rq->bio);
>  	rq->buffer = rq->data = NULL;
>  	rq->data_len = len;
>  	return 0;
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> diff --git a/fs/bio.c b/fs/bio.c
> 
> 
> -
> 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:[~2006-10-02 18:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-01 20:13 GFP_DMA use in SCSI midlayer Andi Kleen
2006-10-01 20:40 ` James Bottomley
2006-10-01 20:55   ` Andi Kleen
2006-10-02 14:52     ` James Bottomley
2006-10-02 19:18       ` Andi Kleen
2006-10-02 22:24         ` Christoph Lameter
2006-10-02 18:43   ` Mike Christie
2006-10-02 18:51     ` Mike Christie [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=45215FAD.3080109@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=James.Bottomley@SteelEye.com \
    --cc=ak@suse.de \
    --cc=clameter@sgi.com \
    --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 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.