On Fri, Mar 08, 2013 at 07:00:55AM -0800, Howard Chu wrote: > Chris Friesen wrote: > >On 03/08/2013 03:40 AM, Howard Chu wrote: > > > >>There is no way that a process that is accessing only 30GB of a mmap > >>should be able to fill up 32GB of RAM. There's nothing else running on > >>the machine, I've killed or suspended everything else in userland > >>besides a couple shells running top and vmstat. When I manually > >>drop_caches repeatedly, then eventually slapd RSS/SHR grows to 30GB and > >>the physical I/O stops. > > > >Is it possible that the kernel is doing some sort of automatic > >readahead, but it ends up reading pages corresponding to data that isn't > >ever queried and so doesn't get mapped by the application? > > Yes, that's what I was thinking. I added a > posix_madvise(..POSIX_MADV_RANDOM) but that had no effect on the > test. > > First obvious conclusion - kswapd is being too aggressive. When free > memory hits the low watermark, the reclaim shrinks slapd down from > 25GB to 18-19GB, while the page cache still contains ~7GB of > unmapped pages. Ideally I'd like a tuning knob so I can say to keep > no more than 2GB of unmapped pages in the cache. (And the desired > effect of that would be to allow user processes to grow to 30GB > total, in this case.) We should find out where the unmapped page cache is coming from if you are only accessing mapped file cache and disabled readahead. How do you arrive at this number of unmapped page cache? What could happen is that previously used and activated pages do not get evicted anymore since there is a constant supply of younger reclaimable cache that is actually thrashing. Whenever you drop the caches, you get rid of those stale active pages and allow the previously thrashing cache to get activated. However, that would require that there is already a significant amount of active file pages before your workload starts (check the nr_active_file number in /proc/vmstat before launching slapd, try sync; echo 3 >drop_caches before launching to eliminate this option) OR that the set of pages accessed during your workload changes and the combined set of pages accessed by your workload is bigger than available memory -- which you claimed would not happen because you only access the 30GB file area on that system. -- 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>