Messages in this thread | | | Date | Sun, 09 Dec 2012 22:59:47 +0100 | From | Zdenek Kabelac <> | Subject | Re: kswapd craziness in 3.7 |
| |
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
| |