[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fszfxk89.fsf@yhuang6-desk1.ccr.corp.intel.com>
Date: Sun, 25 Apr 2021 08:48:22 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Yu Zhao <yuzhao@...gle.com>
Cc: Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, tim.c.chen@...ux.intel.com,
Shakeel Butt <shakeelb@...gle.com>,
Michal Hocko <mhocko@...e.com>, wfg@...l.ustc.edu.cn
Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by
too_many_isolated()
Yu Zhao <yuzhao@...gle.com> writes:
[snip]
> @@ -2966,13 +2938,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
> /* need some check for avoid more shrink_zone() */
> }
>
> - /* See comment about same check for global reclaim above */
> - if (zone->zone_pgdat == last_pgdat)
> - continue;
> - last_pgdat = zone->zone_pgdat;
> shrink_node(zone->zone_pgdat, sc);
> }
>
> + if (last_pgdat)
> + atomic_dec(&last_pgdat->nr_reclaimers);
> + else if (should_retry) {
> + /* wait a bit for the reclaimer. */
> + if (!schedule_timeout_killable(HZ / 10))
Once we reached here, even accidentally, the caller needs to sleep at
least 100ms. How about use a semaphore for pgdat->nr_reclaimers? Then
the sleeper can be waken up when the resource is considered enough.
Best Regards,
Huang, Ying
> + goto retry;
> +
> + /* We are about to die and free our memory. Return now. */
> + sc->nr_reclaimed += SWAP_CLUSTER_MAX;
> + }
> +
> /*
> * Restore to original mask to avoid the impact on the caller if we
> * promoted it to __GFP_HIGHMEM.
[snip]
Powered by blists - more mailing lists