Messages in this thread | | | Date | Wed, 20 Nov 1996 00:38:01 -0500 | From | "David S. Miller" <> | Subject | Re: Bugs and wishes in memory management area |
| |
Date: Tue, 19 Nov 1996 21:39:19 +0100 From: Jean Francois Martinez <jfm@sidney.remcomp.fr>
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 /_____________/ / // /_/ ><
| |