From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752606AbcBLSZa (ORCPT ); Fri, 12 Feb 2016 13:25:30 -0500 Received: from rcdn-iport-1.cisco.com ([173.37.86.72]:29953 "EHLO rcdn-iport-1.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752561AbcBLSZ2 (ORCPT ); Fri, 12 Feb 2016 13:25:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQA3I75W/4wNJK1egzqKGrEyAQ2BZ?= =?us-ascii?q?4YNAoE6OBQBAQEBAQEBgQqEQgEBBCMVUQsYAgIFIQICDwJGBgEMCAEBiBaye45?= =?us-ascii?q?pAQEBAQEBAQEBAQEBAQEBAQEBGAtwhRaENocygToBBI4biFyNVYFehEODA4VSj?= =?us-ascii?q?j4eAQFChAUbhx8HgTIBAQE?= X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="scan'208";a="76451439" Subject: Re: computing drop-able caches To: Dave Hansen , Alexander Viro , Johannes Weiner , Michal Hocko , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Khalid Mughal (khalidm)" , "xe-kernel@external.cisco.com" References: <56AAA77D.7090000@cisco.com> <56BE1F2A.30103@intel.com> <56BE2135.5040407@cisco.com> <56BE21EC.6030708@intel.com> From: Daniel Walker Message-ID: <56BE2396.30801@cisco.com> Date: Fri, 12 Feb 2016 10:25:26 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BE21EC.6030708@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Auto-Response-Suppress: DR, OOF, AutoReply Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/12/2016 10:18 AM, Dave Hansen wrote: > On 02/12/2016 10:15 AM, Daniel Walker wrote: >> On 02/12/2016 10:06 AM, Dave Hansen wrote: >>> On 01/28/2016 03:42 PM, Daniel Walker wrote: >>>> My colleague Khalid and I are working on a patch which will provide a >>>> /proc file to output the size of the drop-able page cache. >>>> One way to implement this is to use the current drop_caches /proc >>>> routine, but instead of actually droping the caches just add >>>> up the amount. >>> Code, please. >> We have a process for release code which doesn't allow us to send it >> immediately. B > OK, how about we continue this discussion once you can release it? I understand you want to see it, and we will release it (sometime today) .. But the code is not sophisticated, it just counts the caches which would be dropped reusing much of fs/drop_caches.c . Daniel