I am quite sure there is still a bug in shrink_caches(), at least there was
one in 2.4.17-rc2. I have not tried later releases, but there is nothing in
the changelog about the fixes anywhere near that area of the code, so I have
to assume the problem is still there.
Here is how one can expose the bug:
- disable kswapd and turn off all swap for simplicity
- run two applications concurrently, one cache intenstive ( eg find / or
simply create/initialize/read a large file), and the other RAM-intensive -
allocate a large block and initialize it
When we get to the point where free memory starts running low, even though we
may have something like 100 MB of cache, shrink_caches() fails to free up
enough memory, which triggers the evil oom killer. Obviously, in the above
situation the correct behaviour is to go on cache diet before considering the
murders.
-- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <sasha@mysql.com> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/