Description of problem: After updating to kernel 2.6.42.7-1.fc15.i686.PAE I'm getting oom-killer activated every few hours. I think this might be related to the bug 745241 or 735946 since I've been using fuse and rsync during that time (regression?). Version-Release number of selected component (if applicable): 2.6.42.7-1.fc15.i686.PAE How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
we can't do anything with this report without seeing logs from the oomkiller.
Created attachment 567529 [details] Section of /var/log/messages This shows what was logged to /var/log/messages when oom-killer activated. Do you need any other logs?
Just got this again now with 2.6.41.10-3 PAE kernel. Attaching dmesg and /var/log/messages
Created attachment 569971 [details] dmesg output
Created attachment 569972 [details] /var/log/messages
Machine has 16 GB RAM and there's a few GB always free (or used by filesystem cache). Swap is either not used or barely (less than 100MB).
Any suggestions on how to debug this?
Is this due to PAE kernel? Do you think changing value for vm.lowmem_reserve_ratio will help?
the real answer is to move to 64bit. Past 8GB, 32bit gets complicated because of so much low memory being used up by page tables. Once fragmentation starts to happen, this sort of thing is to be expected. You might have memory free when the oom is triggering, but the problem is that you don't have any of the right 'type' of memory (the gfp mask) free. You might make it perform a bit better by tweaking syscalls, but you're fundamentally in a losing battle just because you're pushing up against the architectural limits.