Hi,
The following patch adds a config option to get rid of the DMA zone on i386.
Architectures with devices that have no addressing limitations (eg. PPC)
already work this way.
This is useful for custom kernel builds where the developer is certain that
there are no address limitations.
For example, the OLPC machine contains:
- USB devices
- no floppy
- no address limited PCI devices
- no floppy
A unified zone simplifies VM reclaiming work, and also simplifies OOM
killer heuristics (no need to deal with OOM on the DMA zone).
Comments?
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 0d67a0a..8d4dd5e 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -547,6 +547,18 @@ choice
bool "1G/3G user/kernel split"
endchoice
+config NO_DMA_ZONE
+ bool "DMA zone support"
+ default n
+ help
+ This disables support for the 16MiB DMA zone. Only enable this
+ option if you are certain that your devices contain no DMA
+ addressing limitations. A few of them which do:
+ - floppy
+ - ISA devices
+ - some PCI devices (soundcards, etc)
+
+
config PAGE_OFFSET
hex
default 0xB0000000 if VMSPLIT_3G_OPT
diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
index 79df6e6..3078019 100644
--- a/arch/i386/kernel/setup.c
+++ b/arch/i386/kernel/setup.c
@@ -371,9 +371,13 @@ void __init zone_sizes_init(void)
{
unsigned long max_zone_pfns[MAX_NR_ZONES];
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
+#ifndef CONFIG_NO_DMA_ZONE
max_zone_pfns[ZONE_DMA] =
virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+#else
+ max_zone_pfns[ZONE_DMA] = max_low_pfn;
+#endif
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
add_active_range(0, 0, highend_pfn);
On Thu, Dec 28, 2006 at 03:03:02PM -0200, Marcelo Tosatti wrote:
> The following patch adds a config option to get rid of the DMA zone on i386.
>
> Architectures with devices that have no addressing limitations (eg. PPC)
> already work this way.
>
> This is useful for custom kernel builds where the developer is certain that
> there are no address limitations.
>
Don't know if you're aware or not, but there's already a CONFIG_ZONE_DMA
in -mm that accomplishes this, which goes a bit further in that it rips
out all of the generic ZONE_DMA references. Quite a few architectures
that have no interest in the zone are using this already.
On Thu, 2006-12-28 at 15:03 -0200, Marcelo Tosatti wrote:
> Hi,
>
> The following patch adds a config option to get rid of the DMA zone on i386.
>
> Architectures with devices that have no addressing limitations (eg. PPC)
> already work this way.
>
> This is useful for custom kernel builds where the developer is certain that
> there are no address limitations.
>
> For example, the OLPC machine contains:
>
> - USB devices
> - no floppy
> - no address limited PCI devices
> - no floppy
>
> A unified zone simplifies VM reclaiming work, and also simplifies OOM
> killer heuristics (no need to deal with OOM on the DMA zone).
>
> Comments?
Hi,
since one gets random corruption if a user gets this wrong, at least
make things like floppy and all CONFIG_ISA stuff conflict with this
option.... without that your patch feels like a walking time bomb...
(and please include all PCI drivers that only can do 24 bit or 28bit
or .. non-32bit dma as well)
Greetings,
Arjan van de Ven
Arjan van de Ven wrote:
> Hi,
>
> since one gets random corruption if a user gets this wrong, at least
> make things like floppy and all CONFIG_ISA stuff conflict with this
> option.... without that your patch feels like a walking time bomb...
> (and please include all PCI drivers that only can do 24 bit or 28bit
> or .. non-32bit dma as well)
That sounds like a bug if this can happen. Drivers should be failing to
initialize if they can't set the proper DMA mask, and the DMA API calls
should be failing if the requested DMA mask can't be provided.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Thu, 2006-12-28 at 12:34 -0600, Robert Hancock wrote:
Hi,
> > since one gets random corruption if a user gets this wrong, at least
> > make things like floppy and all CONFIG_ISA stuff conflict with this
> > option.... without that your patch feels like a walking time bomb...
> > (and please include all PCI drivers that only can do 24 bit or 28bit
> > or .. non-32bit dma as well)
>
> That sounds like a bug if this can happen. Drivers should be failing to
> initialize if they can't set the proper DMA mask, and the DMA API calls
> should be failing if the requested DMA mask can't be provided.
...but Marcelo's patch doesn't implement anything of that kind....
In addition, many ISA bus drivers do not use the DMA API *at all*
currently. If you want to fix them all up, great! But somehow I doubt
those will get fixed in the next decade.. they've been like this for at
least half a decade or longer :-)
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
On Dec 28 2006 15:03, Marcelo Tosatti wrote:
>
>Comments?
>
>+config NO_DMA_ZONE
^^^^^^
>+ bool "DMA zone support"
^^^
>+ default n
^
>+ help
>+ This disables support for the 16MiB DMA zone. Only enable this
>+ option if you are certain that your devices contain no DMA
>+ addressing limitations.
The naming could be a bit better. If I have
[*] DMA zone support
it should actually enable the DMA zone, not disable it. Wind it like you
prefer, either
(1) config NO_DMA_ZONE, bool "Disable DMA zone" default n or
(2) config DMA_ZONE, bool "[Enable] DMA zone" default y
-`J'
--
Arjan van de Ven wrote:
> ...but Marcelo's patch doesn't implement anything of that kind....
> In addition, many ISA bus drivers do not use the DMA API *at all*
> currently. If you want to fix them all up, great! But somehow I doubt
> those will get fixed in the next decade.. they've been like this for at
> least half a decade or longer :-)
Point being, if this doesn't already work it's likely a bug even without
this patch. And drivers that don't use the DMA API should at least be
allocating memory with GFP_DMA which should fail if that zone doesn't
contain any memory (and if not, that's likely a bug as well).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/