https://bugzilla.novell.com/show_bug.cgi?id=685777 https://bugzilla.novell.com/show_bug.cgi?id=685777#c8 --- Comment #8 from Mel Gorman <mgorman@novell.com> 2011-07-28 10:05:44 UTC --- (In reply to comment #7)
Mel ! thanks so much for looking into that. Meanwhile I had had a similar problem with just overloading the machine by other means I think.
I wonder - so, it is entirely possible that my problems are related to the Intel SSD I have, is it possible that that exacerbates the paging issues ?
What is the reproduction scenario? The speed of the SSD could be masking the fact that the machine is almost out-of-memory but not enough to trigger the OOM killer. If you have no swap configured and anonymous memory is occupying a high percentage of memory (e.g. 85%) then a significant percentage of time will be spent paging to and from the SSD. On a slower disk, the machine would become extremely unresponsive. This thrashing would be visible as a high page in/out rate in "vmstat -n 1". The percentage of memory that is anonymous can be determined from the nr_active_anon and nr_inactive_anon fields in /proc/vmstat . Can you tell me if this is the case? If so, it's not a bug in the kernel unless it is a memory leak that is causing the lack of memory. Just attaching the contents of /proc/vmstat when the machine is running very slow would be helpful in determining what is going on here.
Is it possible you have a new kernel I can try to see if the issues is fixed?
I didn't build a new kernel with the backport yet. However, unless there is sufficient free memory and kswapd is still using a lot of CPU, the patches will not help. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.