Well the bug is about some modules failing loading with "unable to get
DMA memory". That makes modules unreliable. Of course I don't see
why modules are apparently using GFP_ATOMIC | GFP_DMA. When loading a
module I think we can swap.
No, you cannot page the memory a module uses. I leave the reader to
consider the monsterous races assosciated with a kernel that can page
itself.
But GFP_ATOMIC allocation could be improved because we could discard
unmodified pages I think. Correct me if I am wrong.
It cannot do this reliably, because there is always the danger of
sleeping for some reason.
First: Real swapping. When two processes are fighting for memory and
memory is tight only way to make progress is freezing one of them and
let the other run unimpeded for a few seconds.
Consider the live-lock situations that could lead to.
Second: Linux does not write to swap, pages who have never been
modified like code pages. This way Linux does not lose time wring
them. But because reading from swap is faster I think when a page is
being recalled for thez upteemth time it would be wise to write it to
swap. We will get it faster next times. However it seems it would
greatly complicate the code so perhaps it is not a good idea. (Of
course this does not apply to pages we are dicarding to make a hole
for DMA).
We do this, if a page is unmodified and we have an up to date copy on
either swap or the binary image from where it was executed. Code
pages are modified! The dynamic linker when it performs relocations
to the program text to use shared libraries, it does modify and dirty
them. So they cannot be just dropped, they must be paged to disk.
--------------------------------------------////
Yow! 10.49 MB/s remote host TCP bandwidth ////
over 100Mb/s ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><