From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Tejun Heo <tj@kernel.org>,
Vladimir Davydov <vdavydov@parallels.com>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch 03/12] mm: huge_memory: use GFP_TRANSHUGE when charging huge pages
Date: Tue, 17 Jun 2014 11:30:18 -0400 [thread overview]
Message-ID: <20140617153018.GA7331@cmpxchg.org> (raw)
In-Reply-To: <20140617134745.GB19886@dhcp22.suse.cz>
On Tue, Jun 17, 2014 at 03:47:45PM +0200, Michal Hocko wrote:
> On Mon 16-06-14 15:54:23, Johannes Weiner wrote:
> > Transparent huge page charges prefer falling back to regular pages
> > rather than spending a lot of time in direct reclaim.
> >
> > Desired reclaim behavior is usually declared in the gfp mask, but THP
> > charges use GFP_KERNEL and then rely on the fact that OOM is disabled
> > for THP charges, and that OOM-disabled charges currently skip reclaim.
>
> OOM-disabled charges do one round of reclaim currently.
Oops, fixed in v4.
> > Needless to say, this is anything but obvious and quite error prone.
> >
> > Convert THP charges to use GFP_TRANSHUGE instead, which implies
> > __GFP_NORETRY, to indicate the low-latency requirement.
>
> OK, this makes sense. It would be ideal if we could use the same gfp as
> for allocation but that would be too much churn I guess because some
> allocator use a allocation helper which deduces proper gfp flags without
> giving them back to the caller.
>
> Nevertheless, I would still prefer if 05/12 was moved before
> this patch because this is strictly speaking a behavior change.
Yes, that's bungled up, thanks for catching that. So here is the
order I put it in (reverse git history order of course):
commit d0d31c8d4f4cf91edcffa704e8c65ca62af24cf8
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Mon Apr 14 08:16:09 2014 -0400
mm: memcontrol: retry reclaim for oom-disabled and __GFP_NOFAIL charges
There is no reason why oom-disabled and __GFP_NOFAIL charges should
try to reclaim only once when every other charge tries several times
before giving up. Make them all retry the same number of times.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
commit 69f5c6c1a6553a04d7701012a73b2477df8d5a19
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Thu Jun 5 22:02:26 2014 -0400
mm: huge_memory: use GFP_TRANSHUGE when charging huge pages
Transparent huge page charges prefer falling back to regular pages
rather than spending a lot of time in direct reclaim.
Desired reclaim behavior is usually declared in the gfp mask, but THP
charges use GFP_KERNEL and then rely on the fact that OOM is disabled
for THP charges, and that OOM-disabled charges don't retry reclaim.
Needless to say, this is anything but obvious and quite error prone.
Convert THP charges to use GFP_TRANSHUGE instead, which implies
__GFP_NORETRY, to indicate the low-latency requirement.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
commit d485e6b4ed62885d54c57c18c5427e2f174c9012
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Tue May 27 15:23:18 2014 -0400
mm: memcontrol: reclaim at least once for __GFP_NORETRY
Currently, __GFP_NORETRY tries charging once and gives up before even
trying to reclaim. Bring the behavior on par with the page allocator
and reclaim at least once before giving up.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
This first changes __GFP_NORETRY to provide THP-required semantics,
then switches THP over to it, then fixes oom-disabled/NOFAIL charges.
Does that make more sense?
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>
> Anyway
> Acked-by: Michal Hocko <mhocko@suse.cz>
Thanks!
--
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: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Tejun Heo <tj@kernel.org>,
Vladimir Davydov <vdavydov@parallels.com>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch 03/12] mm: huge_memory: use GFP_TRANSHUGE when charging huge pages
Date: Tue, 17 Jun 2014 11:30:18 -0400 [thread overview]
Message-ID: <20140617153018.GA7331@cmpxchg.org> (raw)
In-Reply-To: <20140617134745.GB19886@dhcp22.suse.cz>
On Tue, Jun 17, 2014 at 03:47:45PM +0200, Michal Hocko wrote:
> On Mon 16-06-14 15:54:23, Johannes Weiner wrote:
> > Transparent huge page charges prefer falling back to regular pages
> > rather than spending a lot of time in direct reclaim.
> >
> > Desired reclaim behavior is usually declared in the gfp mask, but THP
> > charges use GFP_KERNEL and then rely on the fact that OOM is disabled
> > for THP charges, and that OOM-disabled charges currently skip reclaim.
>
> OOM-disabled charges do one round of reclaim currently.
Oops, fixed in v4.
> > Needless to say, this is anything but obvious and quite error prone.
> >
> > Convert THP charges to use GFP_TRANSHUGE instead, which implies
> > __GFP_NORETRY, to indicate the low-latency requirement.
>
> OK, this makes sense. It would be ideal if we could use the same gfp as
> for allocation but that would be too much churn I guess because some
> allocator use a allocation helper which deduces proper gfp flags without
> giving them back to the caller.
>
> Nevertheless, I would still prefer if 05/12 was moved before
> this patch because this is strictly speaking a behavior change.
Yes, that's bungled up, thanks for catching that. So here is the
order I put it in (reverse git history order of course):
commit d0d31c8d4f4cf91edcffa704e8c65ca62af24cf8
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Mon Apr 14 08:16:09 2014 -0400
mm: memcontrol: retry reclaim for oom-disabled and __GFP_NOFAIL charges
There is no reason why oom-disabled and __GFP_NOFAIL charges should
try to reclaim only once when every other charge tries several times
before giving up. Make them all retry the same number of times.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
commit 69f5c6c1a6553a04d7701012a73b2477df8d5a19
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Thu Jun 5 22:02:26 2014 -0400
mm: huge_memory: use GFP_TRANSHUGE when charging huge pages
Transparent huge page charges prefer falling back to regular pages
rather than spending a lot of time in direct reclaim.
Desired reclaim behavior is usually declared in the gfp mask, but THP
charges use GFP_KERNEL and then rely on the fact that OOM is disabled
for THP charges, and that OOM-disabled charges don't retry reclaim.
Needless to say, this is anything but obvious and quite error prone.
Convert THP charges to use GFP_TRANSHUGE instead, which implies
__GFP_NORETRY, to indicate the low-latency requirement.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
commit d485e6b4ed62885d54c57c18c5427e2f174c9012
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Tue May 27 15:23:18 2014 -0400
mm: memcontrol: reclaim at least once for __GFP_NORETRY
Currently, __GFP_NORETRY tries charging once and gives up before even
trying to reclaim. Bring the behavior on par with the page allocator
and reclaim at least once before giving up.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
This first changes __GFP_NORETRY to provide THP-required semantics,
then switches THP over to it, then fixes oom-disabled/NOFAIL charges.
Does that make more sense?
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>
> Anyway
> Acked-by: Michal Hocko <mhocko@suse.cz>
Thanks!
next prev parent reply other threads:[~2014-06-17 15:30 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 19:54 [patch 00/12] mm: memcontrol: naturalize charge lifetime v3 Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 01/12] mm: memcontrol: fold mem_cgroup_do_charge() Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 02/12] mm: memcontrol: rearrange charging fast path Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 03/12] mm: huge_memory: use GFP_TRANSHUGE when charging huge pages Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-17 13:47 ` Michal Hocko
2014-06-17 13:47 ` Michal Hocko
2014-06-17 15:30 ` Johannes Weiner [this message]
2014-06-17 15:30 ` Johannes Weiner
2014-06-17 16:20 ` Michal Hocko
2014-06-17 16:20 ` Michal Hocko
2014-06-17 14:23 ` Michal Hocko
2014-06-17 14:23 ` Michal Hocko
[not found] ` <20140617142317.GD19886-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-06-17 15:38 ` Johannes Weiner
2014-06-17 15:38 ` Johannes Weiner
2014-06-17 15:38 ` Johannes Weiner
2014-06-17 16:27 ` Michal Hocko
2014-06-17 16:27 ` Michal Hocko
[not found] ` <20140617162747.GB9572-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-06-18 20:26 ` Johannes Weiner
2014-06-18 20:26 ` Johannes Weiner
2014-06-18 20:26 ` Johannes Weiner
2014-06-16 19:54 ` [patch 04/12] mm: memcontrol: retry reclaim for oom-disabled and __GFP_NOFAIL charges Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
[not found] ` <1402948472-8175-5-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-06-17 13:53 ` Michal Hocko
2014-06-17 13:53 ` Michal Hocko
2014-06-17 13:53 ` Michal Hocko
[not found] ` <20140617135344.GC19886-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-06-17 15:45 ` Johannes Weiner
2014-06-17 15:45 ` Johannes Weiner
2014-06-17 15:45 ` Johannes Weiner
2014-06-17 16:30 ` Michal Hocko
2014-06-17 16:30 ` Michal Hocko
2014-06-16 19:54 ` [patch 05/12] mm: memcontrol: reclaim at least once for __GFP_NORETRY Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 06/12] mm: memcontrol: simplify move precharge function Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-17 14:59 ` Michal Hocko
2014-06-17 14:59 ` Michal Hocko
2014-06-16 19:54 ` [patch 07/12] mm: memcontrol: catch root bypass in move precharge Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 08/12] mm: memcontrol: use root_mem_cgroup res_counter Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
[not found] ` <1402948472-8175-1-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-06-16 19:54 ` [patch 09/12] mm: memcontrol: remove ordering between pc->mem_cgroup and PageCgroupUsed Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 10/12] mm: memcontrol: do not acquire page_cgroup lock for kmem pages Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 11/12] mm: memcontrol: rewrite charge API Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-16 19:54 ` [patch 12/12] mm: memcontrol: rewrite uncharge API Johannes Weiner
2014-06-16 19:54 ` Johannes Weiner
2014-06-17 16:36 ` [patch 00/12] mm: memcontrol: naturalize charge lifetime v3 Michal Hocko
2014-06-17 16:36 ` Michal Hocko
[not found] ` <20140617163615.GD9572-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-06-18 20:31 ` Johannes Weiner
2014-06-18 20:31 ` Johannes Weiner
2014-06-18 20:31 ` Johannes Weiner
2014-06-18 20:36 ` Andrew Morton
2014-06-18 20:36 ` Andrew Morton
2014-06-18 21:02 ` Michal Hocko
2014-06-18 21:02 ` Michal Hocko
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=20140617153018.GA7331@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=tj@kernel.org \
--cc=vdavydov@parallels.com \
/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.