public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: Olaf Kirch <okir@lst.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] Make SG_SET_FORCE_LOW_DMA behave as advertised
Date: Mon, 12 Mar 2007 11:23:22 -0500	[thread overview]
Message-ID: <45F57E7A.1040009@cs.wisc.edu> (raw)
In-Reply-To: <200703121418.31088.okir@lst.de>

Olaf Kirch wrote:
> Make SG_SET_FORCE_LOW_DMA behave as advertised
> 
> I came across this by accident. I have serious doubts whether ISA DMA
> is really relevant these days :-) but what the heck. Feel free to disregard
> if this code is headed for the recycler anyway.
> 
> The SCSI-HOWTO says this about SG_SET_FORCE_LOW_DMA:
> 
> 	If the "reserved" buffer allocated on open() is not in use then
> 	it will be de-allocated and re-allocated under the 16MB level
> 	(and the latter operation could fail yielding ENOMEM).
> 
> I came across this by accident - the current code will never reallocate
> the buffer during the ioctl, because it first sets sfp->low_dma to 1,
> and then checks the very same variable for equality with 0.
> 
> The patch below changes the order of commands, and also moves
> the buffer reallocation around so that it also happens when
> the device has unchecked_isa_dma set.

It might be needed. The removal was my fault. If you are just worried
about using the right memory and the host had unchecked_isa_dma set, the
buffer is now bounced for sg by the block layer helpers so sg does not
need to worry about that.

The problem with this is that the sg code would allocate large chunks of
memory so it would try to make large segments, and if you were trying to
do a really large IO then the isa_page_pool may not work like the old sg
code.

      reply	other threads:[~2007-03-12 16:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-12 13:18 [PATCH] Make SG_SET_FORCE_LOW_DMA behave as advertised Olaf Kirch
2007-03-12 16:23 ` 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=45F57E7A.1040009@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=linux-scsi@vger.kernel.org \
    --cc=okir@lst.de \
    /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