Description of problem: I have 2GB of swap, but every time that I check there is no swap being used. When swapping is required, the oom killer starts to kill processes. Version-Release number of selected component (if applicable): kernel-2.6.13-1.1532_FC4 How reproducible: always Steps to Reproduce: 1. start a process that will require swapping 2. 3. Actual results: oom killer starts Expected results: Additional info: I don't know how to give more information.
swapon yields: [seward@sonylap1 ~]$ /sbin/swapon -s Filename Type Size Used Priority /dev/mapper/VolGroup00-LogVol01 partition 2031608 0 -1
please show the output of 'dmesg' after an oom kill.
Created attachment 120793 [details] dmesg after an oom kill
theres no oom kill in that dmesg.
How long after the oom killer messages start showing up on the console do I have to wait?
they should be there instantly.
Created attachment 120821 [details] New dmesg When I'm at runlevel 5 the oom killer messages run all night and still don't return. Executing prelink in runlevel 3 invokes the oom killer but usually does not result in a responsive system. After several tries, I was able to end up with a responsible enough system to redirect the dmesg output to a file. I've attached that file.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
can you paste the output of "slabtop -sc" after the oom killer has kicked in?
Created attachment 121026 [details] kernel 1636: dmesg Here is the dmesg after the oom killer with kernel 1636
Created attachment 121028 [details] kernel 1636: slabtop -o -sc Here is the result of slabtop -o -sc after the oom killer with kernel 1636
Oops! I just noticed that you asked about kernel 163_7_. I'm downloading now.
Created attachment 121034 [details] kernel 1637: dmesg
Created attachment 121035 [details] kernel 1637: slabtop -o -sc
there's a 1640 being built right now which will appear at http://people.redhat.com/davej/kernels/Fedora/FC4/ in a while, which contains a fix for a memory leak in the file leases code. This could explain why all your memory is being consumed by slab cache. If this solves your problem, then this is a dupe of bug 172691
Created attachment 121074 [details] kernel 1640: dmesg
Created attachment 121075 [details] kernel 1640: dmesg
Created attachment 121076 [details] kernel 1640: slabtop -o -sc
Kernel 1640 was did not fix the problem.
kernel-2.6.14-1.1644_FC4 did not help things.
Do you want new dmesg and slabtop output?
yes please.
Created attachment 121724 [details] kernel 1644: dmesg
Created attachment 121725 [details] kernel 1644: slabtop -o -sc
I have been able to get the system to use some swap by opening several large mozilla sessions, Matlab and VMware. This seems to work OK, but prelink still triggers the oom kller.
what we really need to know is whats happening in the slabcache at the time that the kill happens. Can you run slabtop in an xterm, and trigger the prelink cronjob manually, and watch the output. Do you see buffer_head growing to the top of the list perhaps, and then disappearing after the kill ?
size-64 gets huge right before the kill
I can no longer replicate the bug with kernel version 2.6.14-1.1656_FC4.