From: Vladimir Davydov <vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
kernel-team-b10kYP2dOMg@public.gmane.org
Subject: Re: [PATCH 3/4] memcg: punt high overage reclaim to return-to-userland path
Date: Fri, 28 Aug 2015 23:45:54 +0300 [thread overview]
Message-ID: <20150828204554.GM9610@esperanza> (raw)
In-Reply-To: <20150828171322.GC21463-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On Fri, Aug 28, 2015 at 07:13:22PM +0200, Michal Hocko wrote:
...
> > * If the allocation doesn't have __GFP_WAIT, direct reclaim is
> > skipped. If a process performs only speculative allocations, it can
> > blow way past the high limit. This is actually easily reproducible
> > by simply doing "find /". VFS tries speculative !__GFP_WAIT
> > allocations first, so as long as there's memory which can be
> > consumed without blocking, it can keep allocating memory regardless
> > of the high limit.
>
> It is a bit confusing that you are talking about direct reclaim but in
> fact mean high limit reclaim. But yeah, you are right there is no
> protection against GFP_NOWAIT allocations there.
Actually, memory.high by itself *is* the protection against GFP_NOWAIT
allocations, similarly to zone watermarks. W/o it we would have no other
choice but fail a GFP_NOWAIT allocation on hitting memory.max. One
should just set it so that
memory.max - memory.high > [max sum size of !__GFP_WAIT allocations
that can normally occur in a row]
That being said, currently I don't see any point in making memory.high
!__GFP_WAIT-safe.
Thanks,
Vladimir
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Tejun Heo <tj@kernel.org>,
hannes@cmpxchg.org, cgroups@vger.kernel.org, linux-mm@kvack.org,
kernel-team@fb.com
Subject: Re: [PATCH 3/4] memcg: punt high overage reclaim to return-to-userland path
Date: Fri, 28 Aug 2015 23:45:54 +0300 [thread overview]
Message-ID: <20150828204554.GM9610@esperanza> (raw)
In-Reply-To: <20150828171322.GC21463@dhcp22.suse.cz>
On Fri, Aug 28, 2015 at 07:13:22PM +0200, Michal Hocko wrote:
...
> > * If the allocation doesn't have __GFP_WAIT, direct reclaim is
> > skipped. If a process performs only speculative allocations, it can
> > blow way past the high limit. This is actually easily reproducible
> > by simply doing "find /". VFS tries speculative !__GFP_WAIT
> > allocations first, so as long as there's memory which can be
> > consumed without blocking, it can keep allocating memory regardless
> > of the high limit.
>
> It is a bit confusing that you are talking about direct reclaim but in
> fact mean high limit reclaim. But yeah, you are right there is no
> protection against GFP_NOWAIT allocations there.
Actually, memory.high by itself *is* the protection against GFP_NOWAIT
allocations, similarly to zone watermarks. W/o it we would have no other
choice but fail a GFP_NOWAIT allocation on hitting memory.max. One
should just set it so that
memory.max - memory.high > [max sum size of !__GFP_WAIT allocations
that can normally occur in a row]
That being said, currently I don't see any point in making memory.high
!__GFP_WAIT-safe.
Thanks,
Vladimir
--
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:[~2015-08-28 20:45 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 15:25 [PATCHSET] memcg: improve high limit behavior and always enable kmemcg on dfl hier Tejun Heo
2015-08-28 15:25 ` Tejun Heo
[not found] ` <1440775530-18630-1-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2015-08-28 15:25 ` [PATCH 1/4] memcg: fix over-high reclaim amount Tejun Heo
2015-08-28 15:25 ` Tejun Heo
2015-08-28 17:06 ` Michal Hocko
[not found] ` <20150828170612.GA21463-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-08-28 18:32 ` Tejun Heo
2015-08-28 18:32 ` Tejun Heo
[not found] ` <20150828183209.GA9423-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-08-31 7:51 ` Michal Hocko
2015-08-31 7:51 ` Michal Hocko
[not found] ` <20150831075133.GA29723-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-08-31 13:38 ` Tejun Heo
2015-08-31 13:38 ` Tejun Heo
2015-09-01 12:51 ` Michal Hocko
[not found] ` <20150901125149.GD8810-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-09-01 18:33 ` Tejun Heo
2015-09-01 18:33 ` Tejun Heo
2015-08-28 15:25 ` [PATCH 2/4] memcg: flatten task_struct->memcg_oom Tejun Heo
2015-08-28 15:25 ` Tejun Heo
[not found] ` <1440775530-18630-3-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2015-08-28 17:11 ` Michal Hocko
2015-08-28 17:11 ` Michal Hocko
2015-08-28 15:25 ` [PATCH 3/4] memcg: punt high overage reclaim to return-to-userland path Tejun Heo
2015-08-28 15:25 ` Tejun Heo
[not found] ` <1440775530-18630-4-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2015-08-28 16:36 ` Vladimir Davydov
2015-08-28 16:36 ` Vladimir Davydov
2015-08-28 16:48 ` Tejun Heo
2015-08-28 16:48 ` Tejun Heo
2015-08-28 20:32 ` Vladimir Davydov
2015-08-28 20:44 ` Tejun Heo
2015-08-28 20:44 ` Tejun Heo
2015-08-28 22:06 ` Tejun Heo
[not found] ` <20150828220632.GF11089-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2015-08-29 7:59 ` Vladimir Davydov
2015-08-29 7:59 ` Vladimir Davydov
2015-08-30 15:52 ` Vladimir Davydov
2015-08-28 17:13 ` Michal Hocko
2015-08-28 17:13 ` Michal Hocko
[not found] ` <20150828171322.GC21463-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-08-28 17:56 ` Tejun Heo
2015-08-28 17:56 ` Tejun Heo
2015-08-28 20:45 ` Vladimir Davydov [this message]
2015-08-28 20:45 ` Vladimir Davydov
2015-08-28 20:53 ` Tejun Heo
2015-08-28 20:53 ` Tejun Heo
[not found] ` <20150828205301.GB11089-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2015-08-28 21:07 ` Vladimir Davydov
2015-08-28 21:07 ` Vladimir Davydov
2015-08-28 21:14 ` Tejun Heo
2015-08-28 21:14 ` Tejun Heo
2015-08-28 15:25 ` [PATCH 4/4] memcg: always enable kmemcg on the default hierarchy Tejun Heo
2015-08-28 15:25 ` Tejun Heo
[not found] ` <1440775530-18630-5-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2015-08-28 16:49 ` Vladimir Davydov
2015-08-28 16:49 ` Vladimir Davydov
2015-08-28 16:56 ` Tejun Heo
2015-08-28 17:14 ` Michal Hocko
2015-08-28 17:14 ` Michal Hocko
2015-08-28 17:41 ` Tejun Heo
2015-09-01 12:44 ` Michal Hocko
[not found] ` <20150901124459.GC8810-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-09-01 18:51 ` Tejun Heo
2015-09-01 18:51 ` Tejun Heo
2015-09-04 13:30 ` Michal Hocko
[not found] ` <20150904133038.GC8220-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-09-04 15:38 ` Vladimir Davydov
2015-09-04 15:38 ` Vladimir Davydov
2015-09-07 9:39 ` Michal Hocko
2015-09-07 9:39 ` Michal Hocko
2015-09-07 10:01 ` Vladimir Davydov
2015-09-07 11:03 ` Michal Hocko
2015-09-04 16:18 ` Tejun Heo
[not found] ` <20150904161845.GB25329-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-09-07 10:54 ` Michal Hocko
2015-09-07 10:54 ` Michal Hocko
2015-09-08 18:50 ` Tejun Heo
2015-11-05 17:30 ` 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=20150828204554.GM9610@esperanza \
--to=vdavydov-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=kernel-team-b10kYP2dOMg@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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.