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 S1758665AbdAJXwg (ORCPT <rfc822;w@1wt.eu>);
        Tue, 10 Jan 2017 18:52:36 -0500
Received: from mail-pf0-f175.google.com ([209.85.192.175]:34219 "EHLO
        mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752158AbdAJXwd (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 10 Jan 2017 18:52:33 -0500
Date: Tue, 10 Jan 2017 15:52:31 -0800 (PST)
From: David Rientjes <rientjes@google.com>
X-X-Sender: rientjes@chino.kir.corp.google.com
To: Vlastimil Babka <vbabka@suse.cz>
cc: Hugh Dickins <hughd@google.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Andrew Morton <akpm@linux-foundation.org>,
        Michal Hocko <mhocko@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] mm, thp: add new background defrag option
In-Reply-To: <a00566c2-6fe4-90ce-6689-476619c556b8@suse.cz>
Message-ID: <alpine.DEB.2.10.1701101547560.32737@chino.kir.corp.google.com>
References: <alpine.DEB.2.10.1701041532040.67903@chino.kir.corp.google.com> <20170105101330.bvhuglbbeudubgqb@techsingularity.net> <fe83f15e-2d9f-e36c-3a89-ce1a2b39e3ca@suse.cz> <alpine.DEB.2.10.1701051446140.19790@chino.kir.corp.google.com>
 <558ce85c-4cb4-8e56-6041-fc4bce2ee27f@suse.cz> <alpine.DEB.2.10.1701061407300.138109@chino.kir.corp.google.com> <baeae644-30c4-5f99-2f99-6042766d7885@suse.cz> <alpine.DEB.2.10.1701091818340.61862@chino.kir.corp.google.com> <alpine.LSU.2.11.1701091925170.2692@eggly.anvils>
 <a00566c2-6fe4-90ce-6689-476619c556b8@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 Tue, 10 Jan 2017, Vlastimil Babka wrote:

> > I get very confused by the /sys/kernel/mm/transparent_hugepage/defrag
> > versus enabled flags, and this may be a terrible, even more confusing,
> > idea: but I've been surprised and sad to see defrag with a "defer"
> > option, but poor enabled without one; and it has crossed my mind that
> > perhaps the peculiar "madvise+defer" syntax in defrag might rather be
> > handled by "madvise" in defrag with "defer" in enabled?  Or something
> > like that: 4 x 4 possibilities instead of 5 x 3.
> 
> But would all the possibilities make sense? For example, if I saw
> "defer" in enabled, my first expectation would be that it would only use
> khugepaged, and no THP page faults at all - possibly including madvised
> regions.
> 

And this is why I've tried to minimize the config requirements and respect 
userspace decisions to do MADV_HUGEPAGE, MADV_NOHUGEPAGE, or set/clear 
PR_SET_THP_DISABLE because all these system-wide options combined with 
userspace syscalls truly seems unmaintainable and waay too confusing to 
correctly describe.  Owell, I am fine with introducing 
yet-another-defrag-mode if it lets us move in a direction that supports 
our usecase.