If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
(as I think you're proposing doing for PPC64 (and ia64?)), then the
allocation will fail.
I would not presume proposing anything for PPC64 and left everything the
way it is. The arch people can control if they want ZONE DMA or not and
the default is to leave things as is. If PPC64 wants to go ZONE_DMAless
then the arch code needs to be modified not refer to ZONE_DMA anymore and
if that works then we can switch CONFIG_ZONE_DMA off for PPC64. See the
patches in mm for examples how other arches have done it.
Sorry, there was some confusion then, maybe I misunderstood one of your
earlier emails.
So are we saying that no driver code should be calling with GFP_DMA
(a quick grep turns up 148 instances under driver/), that if they do
they should only work on specific architectures (some instances were
s390-only drivers)? If so, should we not be removing the definiton of
GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
compile time, rather than runtime?
This was covered at length before. Removing all GFP_DMA references would
require extensive #ifdefs. The limited patch in mm is only neutering
GFP_DMA for arches that do not need it. If an arch has removed its definition of
CONFIG_ZONE_DMA then __GFP_DMA will be ignored in the page allocator.
Just ignoring GFP_DMA in the allocator seems like a horrible violation
to me. GFP_DMA means "give me memory from ZONE_DMA". We're both well
aware that the whole concept of ZONE_DMA doesn't make much sense, but
still, that's what it does.
So if you just put all of memory in ZONE_DMA for your particular
machine, and bumped the DMA limit up to infinity, we wouldn't need
any of these patches, right? Which would also match what the other
arches do for this (eg PPC64).
Seems like a much simpler way of solving the problem to me. Or do you
think that won't work for some reason?
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
