Messages in this thread | | | Date | Tue, 17 Nov 1998 10:05:10 -0500 (EST) | From | David Mansfield <> | Subject | MM observation (pathological swap using less than phys. ram) |
| |
Hello. This is not a "bug report," but rather an observation about something a bit less than ideal, IMHO. I have a program called "hog" which swallows a specified amount of memory, and then random accesses it until terminated. This keeps the memory from "laying about" in swap! A test I like to run I've named 'whomp.sh' which runs some number of 'hogs' simultaneously. So here's the scenario:
I have 96MB ram, and hog configured to use 10M ram (10*1024*1024 as arg to malloc). I ran 8 of these suckers, which should account for some 80MB of ram used plus some overhead for the code, local variables etc. This test holds true if run from a VC but I typically run it under an xterm with the exact same results. The results:
Ultimately, all 8 'hogs' get arranged in physical memory. The process counts 'random' accesses per second in each process and display this info, so I can tell the instant all the ram is out of swap because the process will go from about 75 accesses per second to 150000. So, after about 30 minutes all 8 are happily cranking away at the 100000 or so accseses per second. But it takes 30 minutes of pathological swapping to get there.
This is the point: it takes 30 minutes of pathological swapping to arrange 80MB of ram into my 96MB of ram, but ultimately gets there!!!! Why?!? Cross-referenced with 2.0.35: not only is the swapping way down (about 1 minute or 2), but I can actually run 9 'hogs' (90MB committed ram usage) and see about 7 of them cranking away while 2 are in the mud. 2.1.129-pre5 cannot come close to this.
This has been since I caught up with 2.1 around 2.1.115, currently 2.1.129-pre5, on a PPro 200, 96MBram, gcc 2.7.2.3, swap on three IDE disks.
If anyone would like to see my 'hog' let me know, it's as simple as you expect...
David
-- /==============================\ | David Mansfield | | david@cobite.com | \==============================/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |