Dne 9.12.2012 02:01, Linus Torvalds napsal(a):
On Sat, 8 Dec 2012, Zlatko Calusic wrote:
Or sooner... in short: nothing's changed!
On a 4GB RAM system, where applications use close to 2GB, kswapd likes to keep
around 1GB free (unused), leaving only 1GB for page/buffer cache. If I force
bigger page cache by reading a big file and thus use the unused 1GB of RAM,
kswapd will soon (in a matter of minutes) evict those (or other) pages out and
once again keep unused memory close to 1GB.
Ok, guys, what was the reclaim or kswapd patch during the merge window
that actually caused all of these insane problems? It seems it was more
fundamentally buggered than the fifteen-million fixes for kswapd we have
already picked up.
(Ok, I may be exaggerating the number of patches, but it's starting to
feel that way - I thought that 3.7 was going to be a calm and easy
release, but the kswapd issues seem to just keep happening. We've been
fighting the kswapd changes for a while now.)
Trying to keep a gigabyte free (presumably because that way we have lots
of high-order alloction pages) is ridiculous. Is it one of the compaction
changes?
Mel? Ideas?
Very true
It's just as simple a making
dd if=/dev/zero of=/tmp/zero bs=1M count=0 seek=1000000
and now
dd if=/tmp/zero of=/dev/null bs=1M
and kswapd fights with dd for CPU time....
Zdenek
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>