ZONE_DMA32
[Posted September 20, 2005 by corbet]
Linux systems typically divide main memory into three zones. Most memory
fits into the "normal" zone,
ZONE_NORMAL. At the low end,
however, there are 16MB of memory which are partitioned into the DMA zone
ZONE_DMA; this memory is then reserved for situations where it is
specifically needed. The most common user of DMA memory is older
peripherals which can only address 24 bits of memory. Finally, on the high
end,
ZONE_HIGHMEM contains all memory which cannot be directly
addressed by the kernel.
Not all systems implement all of these zones. Some newer architectures do
not support ancient peripherals and leave out ZONE_DMA. In
general, 64-bit systems have no addressing problems and do not need
ZONE_HIGHMEM. The ia64 architecture settled on a different
implementation of ZONE_DMA, defining it to cover all memory
addressed below 4GB.
As it turns out, there are uses for a 4GB zone. Quite a few devices have
trouble accessing memory which cannot be addressed with 32 bits. Drivers
for such devices have been forced to use ZONE_DMA, the I/O memory
management unit (on systems which have one), or bounce buffers. None of
those solutions is ideal: ZONE_DMA is a small and scarce resource,
IOMMU space can also be scarce, and bounce buffers are slow. All of these
problems could be avoided if DMA memory could be reliably allocated below
the 4GB boundary.
Andi Kleen has decided that the time has come for the x86-64 architecture
to support a 32-bit DMA zone. So his patch adds a new zone
(ZONE_DMA32) and an associated GFP flag (GFP_DMA32) for
allocations. According to Andi, the reason which prevented the addition of
this zone in the first place (the fact that the virtual memory subsystem
had a very hard time balancing memory between zones) has gone away.
Meanwhile, the lack of this zone is causing real problems.
This patch does not actually add the new zone for any architecture except
x86-64. For ia64, it causes GFP_DMA to mean the same thing as
GFP_DMA32, with the idea that GFP_DMA should, once again,
be restricted to the older, 24-bit meaning. The patch also causes the
generic DMA code to use the new zone when it makes sense, making it
available to properly-written drivers with no additional work required.
This patch has come too late for inclusion into 2.6.14, but expect to see
it in a mainline kernel shortly thereafter.
(
Log in to post comments)