From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754252AbcBPIWs (ORCPT ); Tue, 16 Feb 2016 03:22:48 -0500 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:6156 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754146AbcBPIWo (ORCPT ); Tue, 16 Feb 2016 03:22:44 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DRCACr28JWXJbY03ZegzqBP4Joo2cBAQEBAQEGi3CFRoQIhgcEAgKBNU0BAQEBAQEHRECEQQEBAQMBOhwjBQsIAxgJJQ8FJQMHGhOIEge4SQEBCAIeGIUxhH2EGoRSBZZ/jVCOfESNfIRZKC6IXAEBAQ Date: Tue, 16 Feb 2016 19:22:41 +1100 From: Dave Chinner To: Nag Avadhanam Cc: Daniel Walker , Alexander Viro , Khalid Mughal , xe-kernel@external.cisco.com, dave.hansen@intel.com, hannes@cmpxchg.org, riel@redhat.com, Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count Message-ID: <20160216082241.GY19486@dastard> References: <1455308080-27238-1-git-send-email-danielwa@cisco.com> <20160214211856.GT19486@dastard> <56C216CA.7000703@cisco.com> <20160215230511.GU19486@dastard> <56C264BF.3090100@cisco.com> <20160216052852.GW19486@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 15, 2016 at 09:57:42PM -0800, Nag Avadhanam wrote: > On Mon, 15 Feb 2016, Dave Chinner wrote: > >So, to pick a random active server here: > > > > before after > >Active(file): 12103200 kB 24060 kB > >Inactive(file): 5976676 kB 1380 kB > >Mapped: 31308 kB 31308 kB > > > >How much was not reclaimed? Roughly the same number of pages as the > >Mapped count, and that's exactly what we'd expect to see from the > >above page walk counting code. Hence a slightly better approximation > >of the pages that dropping caches will reclaim is: > > > >reclaimable pages = active + inactive - dirty - writeback - mapped > > Thanks Dave. I considered that, but see this. > > Mapped page count below is much higher than the (active(file) + > inactive (file)). Yes. it's all unreclaimable from drop caches, though. > Mapped seems to include all page cache pages mapped into the process > memory, including the shared memory pages, file pages and few other > type > mappings. > > I suppose the above can be rewritten as (mapped is still high): > > reclaimable pages = active + inactive + shmem - dirty - writeback - mapped > > What about kernel pages mapped into user address space? Does "Mapped" > include those pages as well? How do we exclude them? What about > device mappings? Are these excluded in the "Mapped" pages > calculation? /me shrugs. I have no idea - I really don't care about what pages are accounted as mapped. I assumed that the patch proposed addressed your requirements and so I suggested an alternative that provided almost exactly the same information but erred on the side of underestimation and hence solves your problem of drop_caches not freeing as much memory as you expected.... Cheers, Dave. -- Dave Chinner david@fromorbit.com