From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id 373F96B0033 for ; Tue, 10 Jan 2017 18:52:34 -0500 (EST) Received: by mail-pf0-f200.google.com with SMTP id c73so30938112pfb.7 for ; Tue, 10 Jan 2017 15:52:34 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com. [2607:f8b0:400e:c00::22f]) by mx.google.com with ESMTPS id m1si3713909pge.100.2017.01.10.15.52.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 15:52:33 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id f144so45179839pfa.2 for ; Tue, 10 Jan 2017 15:52:33 -0800 (PST) Date: Tue, 10 Jan 2017 15:52:31 -0800 (PST) From: David Rientjes Subject: Re: [patch] mm, thp: add new background defrag option In-Reply-To: Message-ID: References: <20170105101330.bvhuglbbeudubgqb@techsingularity.net> <558ce85c-4cb4-8e56-6041-fc4bce2ee27f@suse.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: Hugh Dickins , Mel Gorman , Andrew Morton , Michal Hocko , Jonathan Corbet , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, linux-mm@kvack.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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org