[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6B2BA408B38BA1478B473C31C3D2074E2DD2208E1C@SV-EXCHANGE1.Corp.FC.LOCAL>
Date: Mon, 10 Feb 2014 13:11:15 -0800
From: Motohiro Kosaki <Motohiro.Kosaki@...fujitsu.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>
CC: Rik van Riel <riel@...hat.com>, Dave Hansen <dave@...1.net>,
Michal Hocko <mhocko@...e.cz>,
Motohiro Kosaki JP <kosaki.motohiro@...fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [patch] drop_caches: add some documentation and info message
> -----Original Message-----
> From: Andrew Morton [mailto:akpm@...ux-foundation.org]
> Sent: Tuesday, February 11, 2014 5:51 AM
> To: Johannes Weiner
> Cc: Rik van Riel; Dave Hansen; Michal Hocko; Motohiro Kosaki JP; KAMEZAWA
> Hiroyuki; linux-mm@...ck.org; linux-kernel@...r.kernel.org
> Subject: Re: [patch] drop_caches: add some documentation and info
> message
>
> On Fri, 7 Feb 2014 16:26:01 -0500 Johannes Weiner <hannes@...xchg.org>
> wrote:
>
> > On Fri, Feb 07, 2014 at 12:31:29PM -0800, Andrew Morton wrote:
> > > On Fri, 7 Feb 2014 13:13:32 -0500 Johannes Weiner
> <hannes@...xchg.org> wrote:
> > >
> > > > @@ -63,6 +64,9 @@ int drop_caches_sysctl_handler(ctl_table *table,
> int write,
> > > > iterate_supers(drop_pagecache_sb, NULL);
> > > > if (sysctl_drop_caches & 2)
> > > > drop_slab();
> > > > + printk_ratelimited(KERN_INFO "%s (%d): dropped kernel
> caches: %d\n",
> > > > + current->comm, task_pid_nr(current),
> > > > + sysctl_drop_caches);
> > > > }
> > > > return 0;
> > > > }
> > >
> > > My concern with this is that there may be people whose
> > > other-party-provided software uses drop_caches. Their machines will
> > > now sit there emitting log messages and there's nothing they can do
> > > about it, apart from whining at their vendors.
> >
> > Ironically, we have a customer that is complaining that we currently
> > do not log these events, and they want to know who in their stack is
> > being idiotic.
>
> Right. But if we release a kernel which goes blah on every write to
> drop_caches, that customer has logs full of blahs which they are now totally
> uninterested in.
Please let me know if I misunderstand something. This patch uses KERN_INFO.
Then, any log shouldn't be emitted by default.
Moreover, if someone change syslog log level to INFO, they are going to see
much prenty annoying and too much logs even if we reject this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists