From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A413C433B4 for ; Wed, 28 Apr 2021 11:55:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E99AF61417 for ; Wed, 28 Apr 2021 11:55:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E99AF61417 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 575E96B0036; Wed, 28 Apr 2021 07:55:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54D646B006E; Wed, 28 Apr 2021 07:55:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EE796B0070; Wed, 28 Apr 2021 07:55:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id 21A4D6B0036 for ; Wed, 28 Apr 2021 07:55:24 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CEFB0181AF5C7 for ; Wed, 28 Apr 2021 11:55:23 +0000 (UTC) X-FDA: 78081620526.01.CEB7551 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf27.hostedemail.com (Postfix) with ESMTP id D653180192E9 for ; Wed, 28 Apr 2021 11:55:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1619610922; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mVaAE5j4PRgNVtKYb1xi0JNMS/yIGUD1+Zz/inuGnBA=; b=ZRf3ph+TnessjTvvtr/DsOTmTdjfYuifQx85GKSChPclLGlKVU+Tca39Ojkq6mbumeZ8+f SeIRObEy8skWFL6/2edyJO7a/ZAN4uDpVLyQjbnrZ2gNIkGY8QiG+hDPcU3xnhUoKyyTws JjS4uZnkl+VychQrxBVVx35+pAxq010= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 23ABBB155; Wed, 28 Apr 2021 11:55:22 +0000 (UTC) Date: Wed, 28 Apr 2021 13:55:21 +0200 From: Michal Hocko To: Yu Zhao Cc: Xing Zhengjun , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ying.huang@intel.com, tim.c.chen@linux.intel.com, Shakeel Butt , wfg@mail.ustc.edu.cn, Rik van Riel , Andrea Arcangeli Subject: Re: [RFC] mm/vmscan.c: avoid possible long latency caused by too_many_isolated() Message-ID: References: <20210416023536.168632-1-zhengjun.xing@linux.intel.com> <7b7a1c09-3d16-e199-15d2-ccea906d4a66@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D653180192E9 X-Stat-Signature: dj4ydif9e63qizubq3ucnchc56enh4au X-Rspamd-Server: rspam02 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619610900-317840 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: [Cc Rik and Andrea] On Thu 22-04-21 11:13:34, Yu Zhao wrote: > On Thu, Apr 22, 2021 at 04:36:19PM +0800, Xing Zhengjun wrote: > > Hi, > >=20 > > In the system with very few file pages (nr_active_file + nr_inacti= ve_file > > < 100), it is easy to reproduce "nr_isolated_file > nr_inactive_file"= , then > > too_many_isolated return true, shrink_inactive_list enter "msleep(100= )", the > > long latency will happen. > >=20 > > The test case to reproduce it is very simple: allocate many huge page= s(near > > the DRAM size), then do free, repeat the same operation many times. > > In the test case, the system with very few file pages (nr_active_file= + > > nr_inactive_file < 100), I have dumpped the numbers of > > active/inactive/isolated file pages during the whole test(see in the > > attachments) , in shrink_inactive_list "too_many_isolated" is very ea= sy to > > return true, then enter "msleep(100)",in "too_many_isolated" sc->gfp_= mask is > > 0x342cca ("_GFP_IO" and "__GFP_FS" is masked) , it is also very easy = to > > enter =E2=80=9Cinactive >>=3D3=E2=80=9D, then =E2=80=9Cisolated > ina= ctive=E2=80=9D will be true. > >=20 > > So I have a proposal to set a threshold number for the total file pa= ges to > > ignore the system with very few file pages, and then bypass the 100ms= sleep. > > It is hard to set a perfect number for the threshold, so I just give = an > > example of "256" for it. > >=20 > > I appreciate it if you can give me your suggestion/comments. Thanks. >=20 > Hi Zhengjun, >=20 > It seems to me using the number of isolated pages to keep a lid on > direct reclaimers is not a good solution. We shouldn't keep going > that direction if we really want to fix the problem because migration > can isolate many pages too, which in turn blocks page reclaim. >=20 > Here is something works a lot better. Please give it a try. Thanks. O do have a very vague recollection that number of reclaimers used to be a criterion in very old days and it has proven to be quite bad in the end. I am sorry but I do not have an reference at hands and do not have time to crawl git history. Maybe Rik/Andrea will remember details. The existing throttling mechanism is quite far from optimal but it aims at handling close to OOM situations where effectivelly a large part of the existing LRUs can be already isolated. We already have a retry logic which is LRU aware in the page allocator (should_reclaim_retry). The logic would have to be extended but that sounds like a better fit for the back off to me. > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index 507d216610bf2..9a09f7e76f6b8 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -951,6 +951,8 @@ typedef struct pglist_data { > =20 > /* Fields commonly accessed by the page reclaim scanner */ > =20 > + atomic_t nr_reclaimers; > + > /* > * NOTE: THIS IS UNUSED IF MEMCG IS ENABLED. > * > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 1c080fafec396..f7278642290a6 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1786,43 +1786,6 @@ int isolate_lru_page(struct page *page) > return ret; > } > =20 > -/* > - * A direct reclaimer may isolate SWAP_CLUSTER_MAX pages from the LRU = list and > - * then get rescheduled. When there are massive number of tasks doing = page > - * allocation, such sleeping direct reclaimers may keep piling up on e= ach CPU, > - * the LRU list will go small and be scanned faster than necessary, le= ading to > - * unnecessary swapping, thrashing and OOM. > - */ > -static int too_many_isolated(struct pglist_data *pgdat, int file, > - struct scan_control *sc) > -{ > - unsigned long inactive, isolated; > - > - if (current_is_kswapd()) > - return 0; > - > - if (!writeback_throttling_sane(sc)) > - return 0; > - > - if (file) { > - inactive =3D node_page_state(pgdat, NR_INACTIVE_FILE); > - isolated =3D node_page_state(pgdat, NR_ISOLATED_FILE); > - } else { > - inactive =3D node_page_state(pgdat, NR_INACTIVE_ANON); > - isolated =3D node_page_state(pgdat, NR_ISOLATED_ANON); > - } > - > - /* > - * GFP_NOIO/GFP_NOFS callers are allowed to isolate more pages, so th= ey > - * won't get blocked by normal direct-reclaimers, forming a circular > - * deadlock. > - */ > - if ((sc->gfp_mask & (__GFP_IO | __GFP_FS)) =3D=3D (__GFP_IO | __GFP_F= S)) > - inactive >>=3D 3; > - > - return isolated > inactive; > -} > - > /* > * move_pages_to_lru() moves pages from private @list to appropriate L= RU list. > * On return, @list is reused as a list of pages to be freed by the ca= ller. > @@ -1924,19 +1887,6 @@ shrink_inactive_list(unsigned long nr_to_scan, s= truct lruvec *lruvec, > struct pglist_data *pgdat =3D lruvec_pgdat(lruvec); > bool stalled =3D false; > =20 > - while (unlikely(too_many_isolated(pgdat, file, sc))) { > - if (stalled) > - return 0; > - > - /* wait a bit for the reclaimer. */ > - msleep(100); > - stalled =3D true; > - > - /* We are about to die and free our memory. Return now. */ > - if (fatal_signal_pending(current)) > - return SWAP_CLUSTER_MAX; > - } > - > lru_add_drain(); > =20 > spin_lock_irq(&lruvec->lru_lock); > @@ -3302,6 +3252,7 @@ static bool throttle_direct_reclaim(gfp_t gfp_mas= k, struct zonelist *zonelist, > unsigned long try_to_free_pages(struct zonelist *zonelist, int order, > gfp_t gfp_mask, nodemask_t *nodemask) > { > + int nr_cpus; > unsigned long nr_reclaimed; > struct scan_control sc =3D { > .nr_to_reclaim =3D SWAP_CLUSTER_MAX, > @@ -3334,8 +3285,17 @@ unsigned long try_to_free_pages(struct zonelist = *zonelist, int order, > set_task_reclaim_state(current, &sc.reclaim_state); > trace_mm_vmscan_direct_reclaim_begin(order, sc.gfp_mask); > =20 > + nr_cpus =3D current_is_kswapd() ? 0 : num_online_cpus(); > + while (nr_cpus && !atomic_add_unless(&pgdat->nr_reclaimers, 1, nr_cpu= s)) { > + if (schedule_timeout_killable(HZ / 10)) > + return SWAP_CLUSTER_MAX; > + } > + > nr_reclaimed =3D do_try_to_free_pages(zonelist, &sc); > =20 > + if (nr_cpus) > + atomic_dec(&pgdat->nr_reclaimers); > + > trace_mm_vmscan_direct_reclaim_end(nr_reclaimed); > set_task_reclaim_state(current, NULL); This will surely break any memcg direct reclaim. --=20 Michal Hocko SUSE Labs