On Tue, Dec 17, 2013 at 10:43:51AM -0500, Johannes Weiner wrote: > On Tue, Dec 17, 2013 at 11:20:07AM +0000, Mel Gorman wrote: > > On Mon, Dec 16, 2013 at 03:52:37PM -0500, Johannes Weiner wrote: > > > On Fri, Dec 13, 2013 at 02:10:06PM +0000, Mel Gorman wrote: > > > > Not signed off. Johannes, was the intent really to decrement the batch > > > > counts regardless of whether the policy was being enforced or not? > > > > > > Yes. Bursts of allocations for which the policy does not get enforced > > > will still create memory pressure and affect cache aging on a given > > > node. So even if we only distribute page cache, we want to distribute > > > it in a way that all allocations on the eligible zones equal out. > > > > This means that allocations for page table pages affects the distribution of > > page cache pages. An adverse workload could time when it faults anonymous > > pages (to allocate anon and page table pages) in batch sequences and then > > access files to force page cache pages to be allocated from a single node. > > > > I think I know what your response will be. It will be that the utilisation of > > the zone for page table pages and anon pages means that you want more page > > cache pages to be allocated from the other zones so the reclaim pressure > > is still more or less even. If this is the case or there is another reason > > then it could have done with a comment because it's a subtle detail. > > Yes, that was the idea, that the cache placement compensates for pages > that still are always allocated on the preferred zone first, so that > the end result is approximately as if round-robin had been applied to > everybody. > Ok, understood. I wanted to be sure that was the thinking behind it. > This should be documented as part of the patch that first diverges > between the allocations that are counted and the allocations that are > round-robined: > > mm: page_alloc: exclude unreclaimable allocations from zone fairness policy > > I'm updating my tree. I'll leave it alone in mine then. We'll figure out how to sync up later. -- Mel Gorman SUSE Labs -- 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>