linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: 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
Date: Fri, 6 Jan 2017 14:20:14 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1701061407300.138109@chino.kir.corp.google.com> (raw)
In-Reply-To: <558ce85c-4cb4-8e56-6041-fc4bce2ee27f@suse.cz>

On Fri, 6 Jan 2017, Vlastimil Babka wrote:

> Deciding between "defer" and "background" is however confusing, and also
> doesn't indicate that the difference is related to madvise.
> 

Any suggestions for a better name for "background" are more than welcome.  

> > The kernel implementation takes less of a priority to userspace 
> > simplicitly, imo, and my patch actually cleans up much of the existing 
> > code and ends up adding fewer lines that yours.  I consider it an 
> > improvement in itself.  I don't see the benefit of allowing combined 
> > options.
> 
> I don't like bikesheding, but as this is about user-space API, more care
> should be taken than for implementation details that can change. Even
> though realistically there will be in 99% of cases only two groups of
> users setting this
> - experts like you who know what they are doing, and confusing names
> won't prevent them from making the right choice
> - people who will blindly copy/paste from the future cargo-cult websites
> (if they ever get updated from the enabled="never" recommendations), who
> likely won't stop and think about the other options.
> 

I think the far majority will go with a third option: simply use the 
kernel default and be unaware of other settings or consider it to be the 
most likely choice solely because it is the kernel default.

I think the kernel default could easily be changed to "background" after 
this and nobody would actually notice, but I don't have a strong 
preference for that.  I think users who notice large thp_fault_fallback 
and want to get the true "transparent" nature of hugepages will 
investigate defragmentation behavior and see "background" is exactly what 
they want.  Indeed, I think that the new "background" mode meshes well 
with the expectation of "transparent" hugepages.  I don't foresee any 
usecase, present or future, for "defer" so I'll simply ignore it.

So whether it's better to do echo background or echo "madvise defer" is 
not important to me, I simply imagine that the combination will be more 
difficult to describe to users.  It would break our userspace to currently 
tests for "[madvise]" and reports that state as strictly madvise to our 
mission control, but I can work around that; not sure if others would 
encounter the same issue (would "[defer madvise]" or "[defer] [madvise]" 
break fewer userspaces?).

I'd leave it to Andrew to decide whether sysfs files should accept 
multiple modes or not.  If you are to propose a patch to do so, I'd 
encourage you to do the same cleanup of triple_flag_store() that I did and 
make the gfp mask construction more straight-forward.  If you'd like to 
suggest a different name for "background", I'd be happy to change that if 
it's more descriptive.

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2017-01-06 22:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-04 23:41 David Rientjes
2017-01-05 10:13 ` Mel Gorman
2017-01-05 10:33   ` Michal Hocko
2017-01-05 13:58   ` Vlastimil Babka
2017-01-05 15:50     ` Michal Hocko
2017-01-05 22:54     ` David Rientjes
2017-01-06  8:41       ` Vlastimil Babka
2017-01-06 14:01         ` Michal Hocko
2017-01-06 22:20         ` David Rientjes [this message]
2017-01-09 10:04           ` Vlastimil Babka
2017-01-09 12:06             ` Vlastimil Babka
2017-01-10  2:19             ` David Rientjes
2017-01-10  3:38               ` Hugh Dickins
2017-01-10  8:44                 ` Vlastimil Babka
2017-01-10 23:52                   ` David Rientjes
2017-01-10 13:01               ` Michal Hocko
2017-01-11  0:15               ` [patch v2] mm, thp: add new defer+madvise " David Rientjes
2017-01-11  7:35                 ` Vlastimil Babka
2017-01-12  8:01                   ` Michal Hocko
2017-01-11  8:56                 ` Mel Gorman
2017-01-12  0:16                 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1701061407300.138109@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox