From: Tejun Heo <tj@kernel.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org,
cgroups@vger.kernel.org, linux-mm@kvack.org,
vdavydov@parallels.com, kernel-team@fb.com
Subject: Re: [PATCH 2/3] memcg: ratify and consolidate over-charge handling
Date: Tue, 15 Sep 2015 11:50:02 -0400 [thread overview]
Message-ID: <20150915155002.GF2905@mtj.duckdns.org> (raw)
In-Reply-To: <20150915080110.GA14532@dhcp22.suse.cz>
Hello, Michal.
On Tue, Sep 15, 2015 at 10:01:10AM +0200, Michal Hocko wrote:
> > > OK the code is easier in the end, although I would argue that try_charge
> > > could return ENOMEM for GFP_NOWAIT instead of overcharging (this would
> > > e.g. allow precharge to bail out earlier). Something for a separate patch I
> > > guess.
> >
> > Hmm... GFP_NOWAIT is failed unless it also has __GFP_NOFAIL.
>
> Yes I wasn't clear, sorry, it fails but TIF_MEMDIE or killed/exiting
> context would still overcharge GFP_NOWAIT requests rather than failing
> them. Something for a separate patch though.
Ah, I see. I'm not sure that'd matter one way or the other tho.
> > I don't even think this is an implementation detail.
>
> I really think this is an implementation detail because we can force
> the implementation to never overcharge. Just retry indefinitely for
But we actively choose not to and I think that's an architectural
decision.
> I am not sure I understand here. High and max are basically resembling
> watermarks for the global case. Sure max/high can be set independently
> which is not the case for the global case which calculates them from
> min_free_kbytes but why would that matter and make them different?
Yes, there are similarities but if we really wanted to emulate global
case, we'd just have the hardlimit and then have async reclaim to keep
certain level of reserves and so on.
I don't think it'd be meaningful to try to follow the limit strictly
under all circumstances. It's not like we can track all memory
consumption to begin with. There always is common consumption which
can't clearly be distributed to specific cgroups which makes literal
strictness rather pointless. Also, I'm pretty sure there will always
be enough cases where it is saner to temporarily breach the limit in
small scale just because exhaustion of memory inside a cgroup doesn't
mean global exhaustion and that's an inherent characteristic of what
memcg does.
Anyways, I don't think this difference in viewpoints matters that
much.
Thanks.
--
tejun
--
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-09-15 15:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-13 20:14 [PATCH 1/3] memcg: collect kmem bypass conditions into __memcg_kmem_bypass() Tejun Heo
2015-09-13 20:14 ` [PATCH 2/3] memcg: ratify and consolidate over-charge handling Tejun Heo
2015-09-13 20:14 ` Tejun Heo
2015-09-13 20:15 ` [PATCH 3/3] memcg: drop unnecessary cold-path tests from __memcg_kmem_bypass() Tejun Heo
2015-09-13 20:15 ` Tejun Heo
2015-09-14 12:51 ` Vladimir Davydov
2015-09-14 12:51 ` Vladimir Davydov
2015-09-14 19:40 ` Michal Hocko
2015-09-14 19:40 ` Michal Hocko
2015-09-14 12:44 ` [PATCH 2/3] memcg: ratify and consolidate over-charge handling Vladimir Davydov
2015-09-14 12:44 ` Vladimir Davydov
2015-09-14 15:51 ` Tejun Heo
2015-09-14 15:51 ` Tejun Heo
2015-09-14 19:32 ` Michal Hocko
2015-09-14 19:56 ` Tejun Heo
2015-09-14 19:56 ` Tejun Heo
2015-09-15 8:01 ` Michal Hocko
2015-09-15 15:50 ` Tejun Heo [this message]
2015-09-14 20:07 ` [PATCH v2 " Tejun Heo
2015-09-15 16:18 ` Johannes Weiner
2015-09-15 16:18 ` Johannes Weiner
2015-09-14 9:03 ` [PATCH 1/3] memcg: collect kmem bypass conditions into __memcg_kmem_bypass() Vladimir Davydov
2015-09-14 9:03 ` Vladimir Davydov
2015-09-14 15:21 ` 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=20150915155002.GF2905@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@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.