From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753758AbbGOWVu (ORCPT <rfc822;w@1wt.eu>);
	Wed, 15 Jul 2015 18:21:50 -0400
Received: from mail-ig0-f181.google.com ([209.85.213.181]:34671 "EHLO
	mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752007AbbGOWVs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 15 Jul 2015 18:21:48 -0400
Date: Wed, 15 Jul 2015 15:21:46 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
X-X-Sender: rientjes@chino.kir.corp.google.com
To: Michal Hocko <mhocko@kernel.org>
cc: Andrew Morton <akpm@linux-foundation.org>,
        Jakob Unterwurzacher <jakobunt@gmail.com>, linux-mm@kvack.org,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] oom: Do not invoke oom notifiers on sysrq+f
In-Reply-To: <20150715094240.GF5101@dhcp22.suse.cz>
Message-ID: <alpine.DEB.2.10.1507151521250.3514@chino.kir.corp.google.com>
References: <1436360661-31928-1-git-send-email-mhocko@suse.com> <1436360661-31928-3-git-send-email-mhocko@suse.com> <alpine.DEB.2.10.1507081636180.16585@chino.kir.corp.google.com> <20150709085505.GB13872@dhcp22.suse.cz> <alpine.DEB.2.10.1507091404200.17177@chino.kir.corp.google.com>
 <20150710074032.GA7343@dhcp22.suse.cz> <alpine.DEB.2.10.1507141458350.16182@chino.kir.corp.google.com> <20150715094240.GF5101@dhcp22.suse.cz>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 15 Jul 2015, Michal Hocko wrote:

> > > Shrinkers are there to reclaim and prevent from OOM. This API is a gray
> > > zone. It looks generic method for the notification yet it allows to
> > > prevent from oom killer. I can imagine somebody might abuse this
> > > interface to implement OOM killer policies.
> > > 
> > > Anyway, I think it would be preferable to kill it altogether rather than
> > > play with its placing. It will always be a questionable API.
> > > 
> > 
> > Agreed.
> 
> In such a case it would be still good to fix the bug fixed by this
> patch.
> 

It's fixed if you follow the suggestion of moving the oom notification out 
of the oom killer where it doesn't belong.