From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>
Subject: Re: [PATCH v2 4/4] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim.
Date: Fri, 6 Apr 2018 14:44:09 +0300 [thread overview]
Message-ID: <72db1bfb-aa79-3764-54fd-2c7ddbd07bea@virtuozzo.com> (raw)
In-Reply-To: <CALvZod7P7cE38fDrWd=0caA2J6ZOmSzEuLGQH9VSaagCbo5O+A@mail.gmail.com>
On 04/06/2018 05:13 AM, Shakeel Butt wrote:
> On Fri, Mar 23, 2018 at 8:20 AM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
>> memcg reclaim may alter pgdat->flags based on the state of LRU lists
>> in cgroup and its children. PGDAT_WRITEBACK may force kswapd to sleep
>> congested_wait(), PGDAT_DIRTY may force kswapd to writeback filesystem
>> pages. But the worst here is PGDAT_CONGESTED, since it may force all
>> direct reclaims to stall in wait_iff_congested(). Note that only kswapd
>> have powers to clear any of these bits. This might just never happen if
>> cgroup limits configured that way. So all direct reclaims will stall
>> as long as we have some congested bdi in the system.
>>
>> Leave all pgdat->flags manipulations to kswapd. kswapd scans the whole
>> pgdat, only kswapd can clear pgdat->flags once node is balance, thus
>> it's reasonable to leave all decisions about node state to kswapd.
>
> What about global reclaimers? Is the assumption that when global
> reclaimers hit such condition, kswapd will be running and correctly
> set PGDAT_CONGESTED?
>
The reason I moved this under if(current_is_kswapd()) is because only kswapd
can clear these flags. I'm less worried about the case when PGDAT_CONGESTED falsely
not set, and more worried about the case when it falsely set. If direct reclaimer sets
PGDAT_CONGESTED, do we have guarantee that, after congestion problem is sorted, kswapd
ill be woken up and clear the flag? It seems like there is no such guarantee.
E.g. direct reclaimers may eventually balance pgdat and kswapd simply won't wake up
(see wakeup_kswapd()).
>> static inline bool bdi_cap_synchronous_io(struct backing_dev_info *bdi)
>> {
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index 4525b4404a9e..44422e1d3def 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -190,6 +190,8 @@ struct mem_cgroup {
>> /* vmpressure notifications */
>> struct vmpressure vmpressure;
>>
>> + unsigned long flags;
>> +
>
> nit(you can ignore it): The name 'flags' is too general IMO. Something
> more specific would be helpful.
>
> Question: Does this 'flags' has any hierarchical meaning? Does
> congested parent means all descendents are congested?
It's the same as with pgdat->flags. Cgroup (or pgdat) is congested if at least one cgroup
in the hierarchy (in pgdat) is congested and the rest are all either also congested or don't have
any file pages to reclaim (nr_file_taken == 0).
> Question: Should this 'flags' be per-node? Is it ok for a congested
> memcg to call wait_iff_congested for all nodes?
>
Yes, it should be per-node. I'll try to replace ->flags with 'bool congested'
in struct mem_cgroup_per_node.
next prev parent reply other threads:[~2018-04-06 11:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 15:20 [PATCH v2 0/4] vmscan per-cgroup reclaim fixes Andrey Ryabinin
2018-03-23 15:20 ` [PATCH v2 1/4] mm/vmscan: Update stale comments Andrey Ryabinin
2018-04-06 16:08 ` Johannes Weiner
2018-03-23 15:20 ` [PATCH v2 2/4] mm/vmscan: remove redundant current_may_throttle() check Andrey Ryabinin
2018-04-06 16:10 ` Johannes Weiner
2018-03-23 15:20 ` [PATCH v2 3/4] mm/vmscan: Don't change pgdat state on base of a single LRU list state Andrey Ryabinin
2018-04-05 22:17 ` Andrew Morton
2018-04-06 1:04 ` Shakeel Butt
2018-04-06 16:28 ` Johannes Weiner
2018-04-06 17:25 ` Andrey Ryabinin
2018-03-23 15:20 ` [PATCH v2 4/4] mm/vmscan: Don't mess with pgdat->flags in memcg reclaim Andrey Ryabinin
2018-04-05 22:18 ` Andrew Morton
2018-04-06 2:13 ` Shakeel Butt
2018-04-06 11:44 ` Andrey Ryabinin [this message]
2018-04-06 14:15 ` Shakeel Butt
2018-04-06 13:52 ` [PATCH] mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-v2-fix Andrey Ryabinin
2018-04-06 14:37 ` Shakeel Butt
2018-04-06 15:09 ` Andrey Ryabinin
2018-04-06 15:22 ` Shakeel Butt
2018-04-06 16:36 ` Johannes Weiner
2018-04-06 18:02 ` [PATCH v3 1/2] mm/vmscan: don't change pgdat state on base of a single LRU list state Andrey Ryabinin
2018-04-06 18:02 ` [PATCH v3 2/2] mm/vmscan: don't mess with pgdat->flags in memcg reclaim Andrey Ryabinin
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=72db1bfb-aa79-3764-54fd-2c7ddbd07bea@virtuozzo.com \
--to=aryabinin@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=rostedt@goodmis.org \
--cc=shakeelb@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