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 S1757311AbcHWHs6 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 23 Aug 2016 03:48:58 -0400
Received: from mail-wm0-f54.google.com ([74.125.82.54]:37678 "EHLO
        mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1757193AbcHWHs4 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 23 Aug 2016 03:48:56 -0400
Date: Tue, 23 Aug 2016 09:48:53 +0200
From: Michal Hocko <mhocko@kernel.org>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Andrew Morton <akpm@linux-foundation.org>, greg@suse.cz,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>,
        Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@quantum.com>,
        Jiri Slaby <jslaby@suse.com>, Olaf Hering <olaf@aepfle.de>,
        Vlastimil Babka <vbabka@suse.cz>, linux-mm@kvack.org,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: OOM detection regressions since 4.7
Message-ID: <20160823074853.GD23577@dhcp22.suse.cz>
References: <20160822093249.GA14916@dhcp22.suse.cz>
 <20160823045245.GC17039@js1304-P5Q-DELUXE>
 <20160823073318.GA23577@dhcp22.suse.cz>
 <20160823074014.GB15849@x4>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160823074014.GB15849@x4>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue 23-08-16 09:40:14, Markus Trippelsdorf wrote:
> On 2016.08.23 at 09:33 +0200, Michal Hocko wrote:
> > On Tue 23-08-16 13:52:45, Joonsoo Kim wrote:
> > [...]
> > > Hello, Michal.
> > > 
> > > I agree with partial revert but revert should be a different form.
> > > Below change try to reuse should_compact_retry() version for
> > > !CONFIG_COMPACTION but it turned out that it also causes regression in
> > > Markus report [1].
> > 
> > I would argue that CONFIG_COMPACTION=n behaves so arbitrary for high
> > order workloads that calling any change in that behavior a regression
> > is little bit exaggerated. Disabling compaction should have a very
> > strong reason. I haven't heard any so far. I am even wondering whether
> > there is a legitimate reason for that these days.
> 
> BTW, the current config description:
> 
>   CONFIG_COMPACTION:
>   Allows the compaction of memory for the allocation of huge pages. 
> 
> doesn't make it clear to the user that this is an essential feature.

Yes I plan to send a clarification patch.
-- 
Michal Hocko
SUSE Labs