diff options
author | Miquel van Smoorenburg <mikevs@xs4all.net> | 2008-06-05 18:14:44 +0200 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2008-06-10 12:22:18 +0200 |
commit | b7f09ae583c49d28b2796d2fa5893dcf822e3a10 (patch) | |
tree | 149ba4d9df0eec4c10689d51b33d1e200a512328 /include/linux/pci.h | |
parent | f529626a86d61897862aa1bbbb4537773209238e (diff) | |
download | blackbird-op-linux-b7f09ae583c49d28b2796d2fa5893dcf822e3a10.tar.gz blackbird-op-linux-b7f09ae583c49d28b2796d2fa5893dcf822e3a10.zip |
x86, pci-dma.c: don't always add __GFP_NORETRY to gfp
Currently arch/x86/kernel/pci-dma.c always adds __GFP_NORETRY
to the allocation flags, because it wants to be reasonably
sure not to deadlock when calling alloc_pages().
But really that should only be done in two cases:
- when allocating memory in the lower 16 MB DMA zone.
If there's no free memory there, waiting or OOM killing is of no use
- when optimistically trying an allocation in the DMA32 zone
when dma_mask < DMA_32BIT_MASK hoping that the allocation
happens to fall within the limits of the dma_mask
Also blindly adding __GFP_NORETRY to the the gfp variable might
not be a good idea since we then also use it when calling
dma_ops->alloc_coherent(). Clearing it might also not be a
good idea, dma_alloc_coherent()'s caller might have set it
on purpose. The gfp variable should not be clobbered.
[ mingo@elte.hu: converted to delta patch ontop of previous version. ]
Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'include/linux/pci.h')
0 files changed, 0 insertions, 0 deletions