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>
next prev 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