From: Andi Kleen <ak@suse.de>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org,
Nick Piggin <nickpiggin@yahoo.com.au>,
Christoph Hellwig <hch@infradead.org>,
Marcelo Tosatti <marcelo@kvack.org>,
Arjan van de Ven <arjan@infradead.org>,
Martin Bligh <mbligh@google.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC 0/8] Optional ZONE_DMA
Date: Mon, 10 Jul 2006 02:02:09 +0200 [thread overview]
Message-ID: <200607100202.09787.ak@suse.de> (raw)
In-Reply-To: <44AFF286.6020601@shaw.ca>
> > On x86_64 systems also usually we do not need ZONE_DMA since there
> > are barely any ISA DMA devices around (or are you still using a floppy?).
> > So for most cases the zone can be dropped. Also if the x86_64 systems
> > has less than 4G RAM or DMA controllers that actually can do 64 bit
> > then we also do not need ZONE_DMA32. My x86_64 system has 1G of
> > memory therefore I can run with a single zone.
>
> Keep in mind that:
Yes we can't really make it optional. There are reasons to use GFP_DMA
even without ISA. Also on x86-64 CONFIG_ISA is never set so it would
completely eliminate GFP_DMA, which we can't do.
That said however nearly users of GFP_DMA outside arch/* are wrong.
They should be all audited and convered to use the PCI DMA API instead.
> -LPC devices like the floppy controller, maybe enhanced parallel, etc.
> may have 24-bit DMA restrictions even if there is no physical ISA bus.
>
> -Even in totally ISA and LPC-free systems, some PCI devices (like those
> that were a quick hack of an ISA device onto PCI) still have 24-bit
> address restrictions. There are other devices that have sub-32-bit DMA
> capabilities, like Broadcom wireless chips that only address 31 bits
> (although I think they are fixing this in the driver). Without the DMA
> zone there is no way to ensure that these requests can be satisfied.
There are also devices with 31 or 30 bits that also fall back to GFP_DMA
and a couple of other cases.
-Andi
next prev parent reply other threads:[~2006-07-10 0:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.3mXwB3pXW7L2KpeFW2PO8SBLhJA@ifi.uio.no>
2006-07-08 17:59 ` [RFC 0/8] Optional ZONE_DMA Robert Hancock
2006-07-09 3:21 ` Christoph Lameter
2006-07-10 0:02 ` Andi Kleen [this message]
2006-07-08 0:05 Christoph Lameter
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=200607100202.09787.ak@suse.de \
--to=ak@suse.de \
--cc=arjan@infradead.org \
--cc=clameter@sgi.com \
--cc=hancockr@shaw.ca \
--cc=hch@infradead.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@kvack.org \
--cc=mbligh@google.com \
--cc=nickpiggin@yahoo.com.au \
/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.