From: Xunlei Pang <xlpang@linux.alibaba.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Roman Gushchin <guro@fb.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/3] mm/vmscan: Enable kswapd to reclaim low-protected memory
Date: Tue, 4 Dec 2018 16:44:40 +0800 [thread overview]
Message-ID: <4e06fac2-7269-23a7-e4f5-18928998ece2@linux.alibaba.com> (raw)
In-Reply-To: <20181204072508.GU31738@dhcp22.suse.cz>
On 2018/12/4 PM 3:25, Michal Hocko wrote:
> On Tue 04-12-18 10:40:29, Xunlei Pang wrote:
>> On 2018/12/4 AM 1:22, Michal Hocko wrote:
>>> On Mon 03-12-18 23:20:31, Xunlei Pang wrote:
>>>> On 2018/12/3 下午7:56, Michal Hocko wrote:
>>>>> On Mon 03-12-18 16:01:18, Xunlei Pang wrote:
>>>>>> There may be cgroup memory overcommitment, it will become
>>>>>> even common in the future.
>>>>>>
>>>>>> Let's enable kswapd to reclaim low-protected memory in case
>>>>>> of memory pressure, to mitigate the global direct reclaim
>>>>>> pressures which could cause jitters to the response time of
>>>>>> lantency-sensitive groups.
>>>>>
>>>>> Please be more descriptive about the problem you are trying to handle
>>>>> here. I haven't actually read the patch but let me emphasise that the
>>>>> low limit protection is important isolation tool. And allowing kswapd to
>>>>> reclaim protected memcgs is going to break the semantic as it has been
>>>>> introduced and designed.
>>>>
>>>> We have two types of memcgs: online groups(important business)
>>>> and offline groups(unimportant business). Online groups are
>>>> all configured with MAX low protection, while offline groups
>>>> are not at all protected(with default 0 low).
>>>>
>>>> When offline groups are overcommitted, the global memory pressure
>>>> suffers. This will cause the memory allocations from online groups
>>>> constantly go to the slow global direct reclaim in order to reclaim
>>>> online's page caches, as kswap is not able to reclaim low-protection
>>>> memory. low is not hard limit, it's reasonable to be reclaimed by
>>>> kswapd if there's no other reclaimable memory.
>>>
>>> I am sorry I still do not follow. What role do offline cgroups play.
>>> Those are certainly not low mem protected because mem_cgroup_css_offline
>>> will reset them to 0.
>>>
>>
>> Oh, I meant "offline groups" to be "offline-business groups", memcgs
>> refered to here are all "online state" from kernel's perspective.
>
> What is offline-business group? Please try to explain the actual problem
> in much more details and do not let us guess.
>
Maybe I choosed the wrong word, let me rephase it, and
here is an example.
root 200GB
/ \
important(100GB) unimportant(100GB+DYNAMIC)
/ | \ / \
docker0 docker1... normal(100GB) oversold(DYNAMIC)
/ | \ / | \
j0 j1 ... w0 w1 ...
"DYNAMIC" is controlled by the cluster job scheduler dynamically,
it periodically samples the available system memory(/proc/meminfo
"MemAvailable"), and use part of that to launch oversold jobs
under some special conditions. When "oversold" is active, the
whole system is put under heavy global memory pressure although
memcgs are not.
IOW "DYNAMIC" is primarily borrowed from "dockers" temporarily,
oversold workers will be killed in a timely fashion if "dockers"
needs their memory back suddenly which is rare.
If kswapd doesn't reclaim low-protected memory configured among
"important" dockers, memory allocations from dockers will trap
into global direct reclaim constantly which harms their performance
and response time. The inactive caches from dockers are allowed
to be reclaimed although they are under low-protected(we used a
simple MAX setting), we allow the inactive low-protected memory
to be reclaimed immediately and asynchronously as long as there's
no unprotected reclaimable memory. Its's also friendly to disk IO.
For really latency-sensitive docker, memory.min is supposed to be
used to guarantee its memory QoS.
Thanks
next prev parent reply other threads:[~2018-12-04 8:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 8:01 [PATCH 1/3] mm/memcg: Fix min/low usage in propagate_protected_usage() Xunlei Pang
2018-12-03 8:01 ` [PATCH 2/3] mm/vmscan: Enable kswapd to reclaim low-protected memory Xunlei Pang
2018-12-03 11:56 ` Michal Hocko
2018-12-03 15:20 ` Xunlei Pang
2018-12-03 17:22 ` Michal Hocko
2018-12-04 2:40 ` Xunlei Pang
2018-12-04 7:25 ` Michal Hocko
2018-12-04 8:44 ` Xunlei Pang [this message]
2018-12-03 8:01 ` [PATCH 3/3] mm/memcg: Avoid reclaiming below hard protection Xunlei Pang
2018-12-03 11:57 ` Michal Hocko
2018-12-04 2:53 ` Xunlei Pang
2018-12-03 11:54 ` [PATCH 1/3] mm/memcg: Fix min/low usage in propagate_protected_usage() Michal Hocko
2018-12-03 14:49 ` Xunlei Pang
2018-12-03 18:00 ` Roman Gushchin
2018-12-05 8:58 ` Xunlei Pang
2018-12-05 23:11 ` Roman Gushchin
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=4e06fac2-7269-23a7-e4f5-18928998ece2@linux.alibaba.com \
--to=xlpang@linux.alibaba.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@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