Results 1 to 2 of 2
Sorry if this has been discussed. I did a search on the forum and did not find the answer. If your search-fu is better than mine, please point me in ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 02-01-2013 #1
- Join Date
- Jan 2008
Kernel OOM from cache not being dropped
Sorry if this has been discussed. I did a search on the forum and did not find the answer. If your search-fu is better than mine, please point me in the right direction.
Here's the problem. Embedded system, no swap. Cache eats up all available RAM during heavy usage. This is not a problem. As soon as user-space program allocates memory, cache gives it up. Everything works as advertised.
However, there's a 3rd party device driver that for certain operations, tries to allocate a 5th order page of physical memory. Well buddyinfo shows there are no 5th order page available -- OOM.
But, as soon as I force a drop cache, plenty becomes available, and the operation proceeds as normal.
So it would seem that when allocating virtual memory, cache is dropped to make that happen. When allocating physical memory, cache doesn't get dropped? That doesn't make sense, because then a full cache will make kernel drivers that require contiguous physical memory to fail, which I think is worse than having slow disk access.
Kernel is 2.6.36, memory compaction is enabled.
Perhaps there's some tuning parameter that I have to set?
- 02-05-2013 #2
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
It sounds like a driver bug to me. The driver should detect the OOM situation and ask the kernel to release adequate cache. I'm not sure what the instructions are for that. You could make the argument that the kernel should deal with that, but the answer to that is "it depends"... It depends upon what mechanisms the driver is using to allocate memory, and what errors it is returning to the kernel itself.
Of course, not knowing what device and driver you are using, and not having any of the associated source code to examine, this is all just speculative.Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!