From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred
Date: Thu, 29 Dec 2016 09:24:49 +0100 [thread overview]
Message-ID: <20161229082449.GC29208@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1612281332320.13632@chino.kir.corp.google.com>
On Wed 28-12-16 13:33:49, David Rientjes wrote:
> On Wed, 28 Dec 2016, Michal Hocko wrote:
>
> > I do care more about _users_ and their _experience_ than what
> > application _writers_ think is the best. This is the whole point
> > of giving the defrag tunable. madvise(MADV_HUGEPAGE) is just a hint to
> > the system that using transparent hugepages is _preferable_, not
> > mandatory. We have an option to allow stalls for those vmas to increase
> > the allocation success rate. We also have tunable to completely ignore
> > it. And we should also have an option to not stall.
> >
>
> The application developer who uses madvise(MADV_HUGEPAGE) is doing so for
> a reason.
and nobody questions that... But the application developer can hardly
forsee the environment where the application runs. And what might
look as a reasonable cost/benefit balance in one setup can turn out
completely wrong in a different one - just consider the fragmentation
which is the primary contributor to stalls. It is hardly predictable
and vary between different workloads/setups a lot. While we have a way
(policty if you will) to tell that madvise should be honored as much
as possible (defrag=madvise) we do not have a way to tell that even
madvised vmas are not worth stalling over because the benefit would not
offset the cost.
> We lack the ability to defragment in the background for all users who
> don't want to block while allowing madvise(MADV_HUGEPAGE) users to block,
> as the changelog for this patch clearly indicates.
And I agree that this is something to be addressed. I just disagree that
this patch is the way how to achieve that.
--
Michal Hocko
SUSE Labs
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred
Date: Thu, 29 Dec 2016 09:24:49 +0100 [thread overview]
Message-ID: <20161229082449.GC29208@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1612281332320.13632@chino.kir.corp.google.com>
On Wed 28-12-16 13:33:49, David Rientjes wrote:
> On Wed, 28 Dec 2016, Michal Hocko wrote:
>
> > I do care more about _users_ and their _experience_ than what
> > application _writers_ think is the best. This is the whole point
> > of giving the defrag tunable. madvise(MADV_HUGEPAGE) is just a hint to
> > the system that using transparent hugepages is _preferable_, not
> > mandatory. We have an option to allow stalls for those vmas to increase
> > the allocation success rate. We also have tunable to completely ignore
> > it. And we should also have an option to not stall.
> >
>
> The application developer who uses madvise(MADV_HUGEPAGE) is doing so for
> a reason.
and nobody questions that... But the application developer can hardly
forsee the environment where the application runs. And what might
look as a reasonable cost/benefit balance in one setup can turn out
completely wrong in a different one - just consider the fragmentation
which is the primary contributor to stalls. It is hardly predictable
and vary between different workloads/setups a lot. While we have a way
(policty if you will) to tell that madvise should be honored as much
as possible (defrag=madvise) we do not have a way to tell that even
madvised vmas are not worth stalling over because the benefit would not
offset the cost.
> We lack the ability to defragment in the background for all users who
> don't want to block while allowing madvise(MADV_HUGEPAGE) users to block,
> as the changelog for this patch clearly indicates.
And I agree that this is something to be addressed. I just disagree that
this patch is the way how to achieve that.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2016-12-29 8:24 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 0:21 [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred David Rientjes
2016-12-22 0:21 ` David Rientjes
2016-12-22 8:31 ` Kirill A. Shutemov
2016-12-22 8:31 ` Kirill A. Shutemov
2016-12-22 10:00 ` Michal Hocko
2016-12-22 10:00 ` Michal Hocko
2016-12-22 21:05 ` David Rientjes
2016-12-22 21:05 ` David Rientjes
2016-12-23 8:51 ` Michal Hocko
2016-12-23 8:51 ` Michal Hocko
2016-12-23 10:01 ` David Rientjes
2016-12-23 10:01 ` David Rientjes
2016-12-23 11:18 ` Michal Hocko
2016-12-23 11:18 ` Michal Hocko
2016-12-23 22:46 ` David Rientjes
2016-12-23 22:46 ` David Rientjes
2016-12-26 9:02 ` Michal Hocko
2016-12-26 9:02 ` Michal Hocko
2016-12-27 0:53 ` David Rientjes
2016-12-27 0:53 ` David Rientjes
2016-12-27 2:32 ` Kirill A. Shutemov
2016-12-27 2:32 ` Kirill A. Shutemov
2016-12-27 9:41 ` Michal Hocko
2016-12-27 9:41 ` Michal Hocko
2016-12-27 21:36 ` David Rientjes
2016-12-27 21:36 ` David Rientjes
2016-12-28 8:48 ` Michal Hocko
2016-12-28 8:48 ` Michal Hocko
2016-12-28 21:33 ` David Rientjes
2016-12-28 21:33 ` David Rientjes
2016-12-29 8:24 ` Michal Hocko [this message]
2016-12-29 8:24 ` Michal Hocko
2016-12-30 12:36 ` Mel Gorman
2016-12-30 12:36 ` Mel Gorman
2016-12-30 12:56 ` Michal Hocko
2016-12-30 12:56 ` Michal Hocko
2016-12-30 14:08 ` Mel Gorman
2016-12-30 14:08 ` Mel Gorman
2016-12-30 22:30 ` David Rientjes
2016-12-30 22:30 ` David Rientjes
2017-01-03 10:37 ` Mel Gorman
2017-01-03 10:37 ` Mel Gorman
2017-01-03 21:57 ` David Rientjes
2017-01-03 21:57 ` David Rientjes
2017-01-04 10:12 ` Mel Gorman
2017-01-04 10:12 ` Mel Gorman
2017-01-04 21:53 ` David Rientjes
2017-01-04 21:53 ` David Rientjes
2017-01-02 8:38 ` Vlastimil Babka
2017-01-02 8:38 ` Vlastimil Babka
2017-01-03 22:44 ` David Rientjes
2017-01-03 22:44 ` David Rientjes
2017-01-04 8:32 ` Vlastimil Babka
2017-01-04 8:32 ` Vlastimil Babka
2017-01-04 9:46 ` Michal Hocko
2017-01-04 9:46 ` Michal Hocko
2017-01-04 22:04 ` David Rientjes
2017-01-04 22:04 ` David Rientjes
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=20161229082449.GC29208@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--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=rientjes@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.