Sami Farin wrote:That means the pageout code was scanning about 70000 pages per second on your system during peak stress. You may have run into a scalability problem in the Linux kernel, where it wants to clear the referenced bit off all the anonymous pages before swapping something out. To make matters worse, that unlucky page gets chosen because it was the page where kswapd started scanning. It has little to do with being the least recently used page, because every anonymous page tends to have its referenced bit set by the time we start scanning. On truly enormous systems, say with 256GB of memory, kswapd sometimes needs to scan hundreds of thousands or even millions of pages before finding something to swap out. Not fun. Is the system trying to evict pages like crazy when your system becomes unusable? If so, I wonder if kswapd is simply doing the wrong thing and trying to evict data from all zones, simply because the highmem zone is low on free pages... -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| H. Peter Anvin | Re: [PATCH] x86: Construct 32 bit boot time page tables in native format. |
| Christoph Lameter | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
git: | |
| Christoph Hellwig | Re: [PATCH 06/32] IGET: Mark iget() and read_inode() as being obsolete [try #2] |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
