linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steffen Persvold <sp@scali.no>
To: Helge Hafting <helgehaf@idb.hist.no>
Cc: Vasu Varma P V <pvvvarma@techmas.hcltech.com>,
	linux-kernel@vger.kernel.org
Subject: Re: DMA memory limitation?
Date: Fri, 06 Jul 2001 11:44:40 +0200	[thread overview]
Message-ID: <3B458888.75C50552@scali.no> (raw)
In-Reply-To: <3B4453E6.F4342781@techmas.hcltech.com> <3B457DE6.AFEE6696@idb.hist.no>

Helge Hafting wrote:
> 
> Vasu Varma P V wrote:
> >
> > Hi,
> >
> > Is there any limitation on DMA memory we can allocate using
> > kmalloc(size, GFP_DMA)? I am not able to acquire more than
> > 14MB of the mem using this on my PCI SMP box with 256MB ram.
> > I think there is restriction on ISA boards of 16MB.
> > Can we increase it ?
> 
> You can allocate a lot more memory for your pci activities.
> No problem there.  Just drop the "GFP_DMA" and you'll get
> up to 1G or so.
> 
> You shouldn't use GFP_DMA because PCI cards don't need that.
> Only ISA cards needs GFP_DMA because they can't use more
> than 16M.  So obviously GFP_DMA is limited to
> 16M because it is really ISA_DMA.
> 
> PCI don't need such special tricks, so don't use GFP_DMA!
> Your PCI cards is able to DMA into any memory, including
> the non-GFP_DMA memory.
> 
> > but we have a macro in include/asm-i386/dma.h,
> > MAX_DMA_ADDRESS  (PAGE_OFFSET+0x1000000).
> >
> > if i change it to a higher value, i am able to get more dma
> > memory. Is there any way i can change this without compiling
> > the kernel?
> >
> No matter what you do, DON'T change that.  Yeah, you'll get
> a bigger GFP_DMA pool, but that'll break each and every
> ISA card that tries to allocate GFP_DMA memory.  You
> achieve exactly the same effect for your PCI card by ditching
> the GFP_DMA parameter, but then you achieve it without breaking
> ISA cards.
> 
A problem arises on 64 bit platforms (such as IA64) if your PCI card is only 32bit (can
address the first 4G) and you don't wan't to use bounce buffers. If you use GFP_DMA on
IA64 you are ensured that the memory you get is below 4G and not 16M as on i386, hence no
bounce buffers are needed. On Alpha GFP_DMA is not limited at all (I think). Correct me if
I'm wrong, but I really think there should be a general way of allocating memory that is
32bit addressable (something like GFP_32BIT?) so you don't need a lot of #ifdef's in your
code.

Regards,
-- 
  Steffen Persvold               Systems Engineer
  Email : mailto:sp@scali.no     Scali AS (http://www.scali.com)
  Tlf   : (+47) 22 62 89 50      Olaf Helsets vei 6
  Fax   : (+47) 22 62 89 51      N-0621 Oslo, Norway

  reply	other threads:[~2001-07-06  9:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-05 11:47 DMA memory limitation? Vasu Varma P V
2001-07-05 11:53 ` Alan Cox
2001-07-05 11:54 ` Arjan van de Ven
2001-07-05 12:37   ` Vasu Varma P V
2001-07-05 12:37 ` Richard B. Johnson
2001-07-05 17:07   ` Christophe Beaumont
2001-07-05 17:19     ` Richard B. Johnson
2001-07-06  8:59 ` Helge Hafting
2001-07-06  9:44   ` Steffen Persvold [this message]
2001-07-06 11:08     ` Alan Cox
2001-07-06 11:27       ` Jeff Garzik
2001-07-06 15:16         ` Steffen Persvold
2001-07-06 15:39           ` Jeff Garzik
2001-07-06 15:48           ` Alan Cox
2001-07-06 15:56 Matt_Domsch

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=3B458888.75C50552@scali.no \
    --to=sp@scali.no \
    --cc=helgehaf@idb.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pvvvarma@techmas.hcltech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).