On Tue, Jul 31, 2018 at 07:09:28PM +0800, Zhaoyang Huang wrote:
> This patch try to let the direct reclaim finish earlier than it used
> to be. The problem comes from We observing that the direct reclaim
> took a long time to finish when memcg is enabled. By debugging, we
> find that the reason is the softlimit is too low to meet the loop
> end criteria. So we add two barriers to judge if it has reclaimed
> enough memory as same criteria as it is in shrink_lruvec:
> 1. for each memcg softlimit reclaim.
> 2. before starting the global reclaim in shrink_zone.
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxxxxxx>
> ---
> include/linux/memcontrol.h | 3 ++-
> mm/memcontrol.c | 3 +++
> mm/vmscan.c | 38 +++++++++++++++++++++++++++++++++++++-
> 3 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 6c6fb11..a7e82c7 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -325,7 +325,8 @@ void mem_cgroup_cancel_charge(struct page *page, struct mem_cgroup *memcg,
> void mem_cgroup_uncharge_list(struct list_head *page_list);
>
> void mem_cgroup_migrate(struct page *oldpage, struct page *newpage);
> -
> +bool direct_reclaim_reach_watermark(pg_data_t *pgdat, unsigned long nr_reclaimed,
> + unsigned long nr_scanned, gfp_t gfp_mask, int order);
> static struct mem_cgroup_per_node *
> mem_cgroup_nodeinfo(struct mem_cgroup *memcg, int nid)
> {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 8c0280b..e4efd46 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2577,6 +2577,9 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order,
> (next_mz == NULL ||
> loop > MEM_CGROUP_MAX_SOFT_LIMIT_RECLAIM_LOOPS))
> break;
> + if (direct_reclaim_reach_watermark(pgdat, nr_reclaimed,
> + *total_scanned, gfp_mask, order))
> + break;
> } while (!nr_reclaimed);
> if (next_mz)
> css_put(&next_mz->memcg->css);
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 03822f8..19503f3 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2518,6 +2518,34 @@ static bool pgdat_memcg_congested(pg_data_t *pgdat, struct mem_cgroup *memcg)
> (memcg && memcg_congested(pgdat, memcg));
> }
>
> +bool direct_reclaim_reach_watermark(pg_data_t *pgdat, unsigned long nr_reclaimed,
> + unsigned long nr_scanned, gfp_t gfp_mask,
> + int order)
> +{
> + struct scan_control sc = {
> + .gfp_mask = gfp_mask,
> + .order = order,
> + .priority = DEF_PRIORITY,
> + .nr_reclaimed = nr_reclaimed,
> + .nr_scanned = nr_scanned,
> + };
> + if (!current_is_kswapd())
> + return false;
> + if (!IS_ENABLED(CONFIG_COMPACTION))
> + return false;
> + /*
> + * In fact, we add 1 to nr_reclaimed and nr_scanned to let should_continue_reclaim
> + * NOT return by finding they are zero, which means compaction_suitable()
> + * takes effect here to judge if we have reclaimed enough pages for passing
> + * the watermark and no necessary to check other memcg anymore.
> + */
> + if (!should_continue_reclaim(pgdat,
> + sc.nr_reclaimed + 1, sc.nr_scanned + 1, &sc))
> + return true;
As per the previous submission, should_continue_reclaim() is really
not an appropriate function to use. It's for the compaction policy.
You might be able to hack around it with faking the reclaim progress,
but this will fail in subtle ways when people change the compaction
policy in that function in the future.
If you use it only for the watermark check, check it explicitly.
Other than that, I agree with Michal that we need much more data on
this; what the configuration is like, what the memory situation is
like when your problem happens, how long the stalls are, and how your
patch helps with overreclaim etc.
