Question about RAM allocation and what 'seems' like very odd swap use

NoeticRapture · 06-25-2005, 04:22 AM

I'm running Slackware on a notebook and even though I stick more or less exclusively to Fluxbox and not KDE or Gnome, I sometimes have literally a dozen or more instances of firefox open simultaneously along with a number of other programs scattered about - but my swap partition never gets used... I've on perhaps 3 occasions in 3-4 months seen it claim to be using somewhere around 100k of the 400mb partition, but it almost looks like I managed to somehow or other make it just plain unusable -- so here's my question...

Am I just too used to Windows after having used it all those years? Or isn't the swap partition available for use for some reason? Here's some of the hardware info...

AMD Athlon XP 2800+ (2.12GHz), IGP320M integrated graphics (set for 64mb out of the 512mb total ram), 60gb HDD with 1 primary partition and the rest logical, in order: 20gb NTFS, 15gb ReiserFS (v3.6), around 20gb vfat, and finally my 400mb swap. It's definitely marked as being of type swap, and swapon happily loads it, etc. Oh, and I'm running a 2.6.12.1. Kernel now, but don't remember it having been any different with the others I've compiled.

Also, if I eliminated the swap partition altogether, how would the system react if I filled the ram to capacity - Kernel panic, crawling at a standstill until some of the RAM cleared, or...? The likely result I mean, I'm sure it isn't quite that predictable in reality.

(first line in my /etc/fstab)

/dev/hda7 swap swap defaults 0 0

win32sux · 06-25-2005, 04:31 AM

if you have 448mb of ram (512 - 64) and fluxbox there's really no reason why you should have swap usage if all you are using is firefox and a few other small apps...

if you've seen your swap usage go up to 100k then you know it's working...

if you would eliminate your swap and your memory would run-out then your system would crash and you'd have to reboot...

keefaz · 06-25-2005, 04:37 AM

win32sux, if the kernel detects that there is no
more ram available, it begins to kill processes
until some amount of ram is free'd
The system won't crash

win32sux · 06-25-2005, 04:50 AM

Quote:

Originally posted by keefaz
win32sux, if the kernel detects that there is no
more ram available, it begins to kill processes
until some amount of ram is free'd
The system won't crash

okay maybe "crash" wasn't the right word... but still, it would "crawl to a standstill"... i know because i've tried it and all i could do was reboot...

as for the "it begins to kill processes", i honestly didn't know that... could you please elaborate?? i was under the impression that what it would do was clear cached memory and make it available - but that once the processes had no more memory available from anywhre well they'd start going into shock and die a segfaultish death... how does the kernel know which processes to start killing once memory runs out?? and why doesn't it seem to do that when i intentionally run my box out of memory?? i'm using 2.4.29...

win32sux · 06-25-2005, 05:00 AM

PS: i'm gonna test this right now again just to be sure... last time i did this i did have a defective ram stick which might have contributed to my crash/freeze... i will now proceed to disable my swap and open all my little apps... i only have 128MB by the way... i'll report in a few minutes...

win32sux · 06-25-2005, 05:13 AM

okay, tried it... my system didn't crash... X11 was automatically killed/restarted (as were all the apps i was running in it) and i was able to log back in and do it all over again - without having to reboot...

so yeah, the crash i was experiencing when doing this before was due to my faulty ramstick - something completely unrelated...

thanks for clearing that up, keefaz...

BTW, i'm still interested in learning what methodology the kernel uses to select which processes to kill when memory runs out...

keefaz · 06-25-2005, 10:12 AM

I think it kills process by PID order
The highest to the lowest (init has PID 1)

Noth · 06-25-2005, 03:03 PM

Quote:

Originally posted by keefaz
I think it kills process by PID order
The highest to the lowest (init has PID 1)

No, there's an algorithm used to determine which process should be killed. From the top of the oom_kill.c file

Code:

 /**
 * oom_badness - calculate a numeric value for how bad this task has been
 * @p: task struct of which task we should calculate
 * @p: current uptime in seconds
 *
 * The formula used is relatively simple and documented inline in the
 * function. The main rationale is that we want to select a good task
 * to kill when we run out of memory.
 *
 * Good in this context means that:
 * 1) we lose the minimum amount of work done
 * 2) we recover a large amount of memory
 * 3) we don't kill anything innocent of eating tons of memory
 * 4) we want to kill the minimum amount of processes (one)
 * 5) we try to kill the process the user expects us to kill, this
 *    algorithm has been meticulously tuned to meet the principle
 *    of least surprise ... (be careful when you change it)
 */

I've had it kill VMWare a few times recently, if the OOM killer kicks in you'll see something like this in your logs:

Quote:

oom-killer: gfp_mask=0xd0
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
cpu 1 hot: low 2, high 6, batch 1
cpu 1 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
HighMem per-cpu: empty

Free pages: 9112kB (0kB HighMem)
Active:183709 inactive:34164 dirty:0 writeback:421 unstable:0 free:2278 slab:7214 mapped:216748 pagetables:673
DMA free:4096kB min:64kB low:80kB high:96kB active:9196kB inactive:0kB present:16384kB pages_scanned:14369 all_unreclaimable? yes
lowmem_reserve[]: 0 1008 1008
Normal free:5016kB min:4032kB low:5040kB high:6048kB active:725640kB inactive:136656kB present:1032192kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 4096kB
Normal: 262*4kB 26*8kB 3*16kB 0*32kB 8*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 5016kB
HighMem: empty
Swap cache: add 12742, delete 11490, find 2323/2666, race 0+0
Free swap = 1524284kB
Total swap = 1536812kB
Out of Memory: Killed process 7032 (vmware-vmx).

win32sux · 06-25-2005, 03:08 PM

thanks for the info, Noth... very interesting stuff...