From: Vladimir Davydov <vdavydov@parallels.com>
To: Tejun Heo <tj@kernel.org>, Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is enabled
Date: Fri, 4 Sep 2015 21:21:11 +0300 [thread overview]
Message-ID: <20150904182110.GE13699@esperanza> (raw)
In-Reply-To: <20150904154448.GA25329@mtj.duckdns.org>
Hi Tejun, Michal
On Fri, Sep 04, 2015 at 11:44:48AM -0400, Tejun Heo wrote:
...
> > I admit I may be mistaken, but if I'm right, we may end up with really
> > complex memcg reclaim logic trying to closely mimic behavior of buddy
> > alloc with all its historic peculiarities. That's why I don't want to
> > rush ahead "fixing" memcg reclaim before an agreement among all
> > interested people is reached...
>
> I think that's a bit out of proportion. I'm not suggesting bringing
> in all complexities of global reclaim. There's no reason to and what
> memcg deals with is inherently way simpler than actual memory
> allocation. The original patch was about fixing systematic failure
> around GFP_NOWAIT close to the high limit. We might want to do
> background reclaim close to max but as long as high limit functions
> correctly, that's much less of a problem at least on the v2 interface.
Looking through this thread once again and weighting my arguments vs
yours, I start to understand that I'm totally wrong and these patches
are not proper fixes for the problem.
Having these patches in the kernel only helps when we are hitting the
hard limit, which shouldn't occur often if memory.high works properly.
Even if memory.high is not used, the only negative effect we would get
w/o them is allocating a slab from a wrong node or getting a low order
page where we could get a high order one. Both should be rare and both
aren't critical. I think I got carried away with all those obscure
"reclaimer peculiarities" at some point.
Now I think task_work reclaim initially proposed by Tejun would be a
much better fix.
I'm terribly sorry for being so annoying and stubborn and want to thank
you for all your feedback!
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-09-04 18:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-30 19:02 Vladimir Davydov
2015-08-30 19:02 ` [PATCH 1/2] mm/slab: skip memcg reclaim only if in atomic context Vladimir Davydov
2015-08-30 19:02 ` [PATCH 2/2] mm/slub: do not bypass memcg reclaim for high-order page allocation Vladimir Davydov
2015-08-31 13:24 ` [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is enabled Michal Hocko
2015-08-31 13:43 ` Tejun Heo
2015-08-31 14:30 ` Vladimir Davydov
2015-08-31 14:39 ` Tejun Heo
2015-08-31 15:18 ` Vladimir Davydov
2015-08-31 15:47 ` Tejun Heo
2015-08-31 16:51 ` Vladimir Davydov
2015-08-31 17:03 ` Tejun Heo
2015-08-31 19:26 ` Vladimir Davydov
2015-08-31 20:22 ` Christoph Lameter
2015-09-01 9:25 ` Vladimir Davydov
2015-08-31 14:20 ` Vladimir Davydov
2015-08-31 14:46 ` Tejun Heo
2015-08-31 15:24 ` Vladimir Davydov
2015-09-01 12:36 ` Michal Hocko
2015-09-01 13:40 ` Vladimir Davydov
2015-09-01 15:01 ` Michal Hocko
2015-09-01 16:55 ` Vladimir Davydov
2015-09-01 18:38 ` Michal Hocko
2015-09-02 9:30 ` Vladimir Davydov
2015-09-02 18:16 ` Christoph Lameter
2015-09-03 9:36 ` Vladimir Davydov
2015-09-03 16:32 ` Tejun Heo
2015-09-04 11:15 ` Vladimir Davydov
2015-09-04 15:44 ` Tejun Heo
2015-09-04 18:21 ` Vladimir Davydov [this message]
2015-09-04 19:30 ` Tejun Heo
2015-09-04 14:38 ` 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=20150904182110.GE13699@esperanza \
--to=vdavydov@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox