Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946067Ab2JYOJg (ORCPT ); Thu, 25 Oct 2012 10:09:36 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45044 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1945971Ab2JYOJd (ORCPT ); Thu, 25 Oct 2012 10:09:33 -0400 Date: Thu, 25 Oct 2012 16:09:31 +0200 From: Michal Hocko To: Andrew Morton Cc: linux-mm@kvack.org, Dave Hansen , KAMEZAWA Hiroyuki , KOSAKI Motohiro , LKML Subject: Re: [PATCH] add some drop_caches documentation and info messsge Message-ID: <20121025140930.GF11105@dhcp22.suse.cz> References: <20121012125708.GJ10110@dhcp22.suse.cz> <20121023164546.747e90f6.akpm@linux-foundation.org> <20121024062938.GA6119@dhcp22.suse.cz> <20121024125439.c17a510e.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121024125439.c17a510e.akpm@linux-foundation.org> 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 Content-Length: 2268 Lines: 49 On Wed 24-10-12 12:54:39, Andrew Morton wrote: > On Wed, 24 Oct 2012 08:29:45 +0200 > Michal Hocko wrote: [...] > hmpf. This patch worries me. If there are people out there who are > regularly using drop_caches because the VM sucks, it seems pretty > obnoxious of us to go dumping stuff into their syslog. What are they > supposed to do? Stop using drop_caches? But that would unfix the > problem which they fixed with drop_caches in the first case. > > And they might not even have control over the code - they need to go > back to their supplier and say "please send me a new version", along > with all the additional costs and risks involed in an update. I understand your worries and that's why I suggested a higher log level which is under admin's control. Does even that sound too excessive? > > > More friendly alternatives might be: > > > > > > - Taint the kernel. But that will only become apparent with an oops > > > trace or similar. > > > > > > - Add a drop_caches counter and make that available in /proc/vmstat, > > > show_mem() output and perhaps other places. > > > > We would loose timing and originating process name in both cases which > > can be really helpful while debugging. It is fair to say that we could > > deduce the timing if we are collecting /proc/meminfo or /proc/vmstat > > already and we do collect them often but this is not the case all of the > > time and sometimes it is important to know _who_ is doing all this. > > But how important is all that? The main piece of information the > kernel developer wants is "this guy is using drop_caches a lot". All > the other info is peripheral and can be gathered by other means if so > desired. Well, I have experienced a debugging session where I suspected that an excessive drop_caches is going on but I had hard time to prove who is doing that (customer, of course, claimed they are not doing anything like that) so we went through many loops until we could point the finger. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/