From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751807AbcFUMPc (ORCPT ); Tue, 21 Jun 2016 08:15:32 -0400 Received: from mail-lb0-f193.google.com ([209.85.217.193]:36717 "EHLO mail-lb0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751659AbcFUMPa (ORCPT ); Tue, 21 Jun 2016 08:15:30 -0400 Date: Tue, 21 Jun 2016 13:17:16 +0200 From: Michal Hocko To: Hillf Danton Cc: "'Oleg Nesterov'" , linux-kernel , linux-mm@kvack.org Subject: Re: [PATCH 03/10] proc, oom_adj: extract oom_score_adj setting into a helper Message-ID: <20160621111716.GD30848@dhcp22.suse.cz> References: <06be01d1cb9c$8f235850$ad6a08f0$@alibaba-inc.com> <06bf01d1cb9f$32a49320$97edb960$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06bf01d1cb9f$32a49320$97edb960$@alibaba-inc.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 21-06-16 17:27:57, Hillf Danton wrote: > > > > From: Michal Hocko > > > > Currently we have two proc interfaces to set oom_score_adj. The legacy > > /proc//oom_adj and /proc//oom_score_adj which both have their > > specific handlers. Big part of the logic is duplicated so extract the > > common code into __set_oom_adj helper. Legacy knob still expects some > > details slightly different so make sure those are handled same way - e.g. > > the legacy mode ignores oom_score_adj_min and it warns about the usage. > > > > This patch shouldn't introduce any functional changes. > > > > Acked-by: Oleg Nesterov > > Signed-off-by: Michal Hocko > > --- > > fs/proc/base.c | 94 +++++++++++++++++++++++++++------------------------------- > > 1 file changed, 43 insertions(+), 51 deletions(-) > > > > diff --git a/fs/proc/base.c b/fs/proc/base.c > > index 968d5ea06e62..a6a8fbdd5a1b 100644 > > --- a/fs/proc/base.c > > +++ b/fs/proc/base.c > > @@ -1037,7 +1037,47 @@ static ssize_t oom_adj_read(struct file *file, char __user *buf, size_t count, > > return simple_read_from_buffer(buf, count, ppos, buffer, len); > > } > > > > -static DEFINE_MUTEX(oom_adj_mutex); > > +static int __set_oom_adj(struct file *file, int oom_adj, bool legacy) > > +{ > > + static DEFINE_MUTEX(oom_adj_mutex); > > Writers are not excluded for readers! > Is this a hot path? I am not sure I follow you question. This is a write path... Who would be the reader? -- Michal Hocko SUSE Labs