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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D31BECD128A for ; Mon, 8 Apr 2024 08:19:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5492C6B0093; Mon, 8 Apr 2024 04:19:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F99C6B0095; Mon, 8 Apr 2024 04:19:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C0306B0096; Mon, 8 Apr 2024 04:19:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1E4B96B0093 for ; Mon, 8 Apr 2024 04:19:42 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BBE1A1C029B for ; Mon, 8 Apr 2024 08:19:41 +0000 (UTC) X-FDA: 81985665762.14.25138D1 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf07.hostedemail.com (Postfix) with ESMTP id D962340012 for ; Mon, 8 Apr 2024 08:19:39 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jwPkJwyS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712564379; h=from:from:sender:reply-to:subject:subject: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:dkim-signature; bh=AX5+jXHMJTfU3cppVGB1oM10Q5k8KJr3dApT/VnvvYU=; b=qov07ebiscaVJ7RK81rPh9lP5+oh7kK8mBCZxc/gc0muBc+l6x3deuAVw/Ogd5OHVJLXbK gHnzO/I89Qin2iendXdUIobit74IaV2Avo49ew0GVGBY/wIh+h87Kvt15qPloLG7E45fb3 WOgMPumopAHObjBvbmewUtjOxaGCbDc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jwPkJwyS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712564379; a=rsa-sha256; cv=none; b=a7iK8IGUnJ6KYLLaPt4nT/ZccU0rl5jwyoDlqE60682CsR5hXyTWXG+AcB3tXRxKD5mMpd UzbEJ0w/LjDZp3nxkwS8owzbMkBB8z6//QOdLVkIYNOjzzKR0fmsJzXxOR6djhEE+Ovj9X D4bG49sfIxyYwWdXEC8CwFcwfGCqD7I= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-7e36fa66672so765081241.2 for ; Mon, 08 Apr 2024 01:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712564379; x=1713169179; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AX5+jXHMJTfU3cppVGB1oM10Q5k8KJr3dApT/VnvvYU=; b=jwPkJwySIt7kgzKrTn57zRReyRQuxj5HrLWaYlF456/pttNhWwpveJvZ2q5Stet8+P 0GbD7h3izRZH1AOiiEaa590MtZCJdoluGWiDdUmHA9YSsQ+rUbNXT9ab76ElSSK4/ZGQ GTpVndfZFylKzOZb01P36wgMhvNm3KUtqOBNye/lx9806txgJHF61D300u05XjUFp606 A8M/F84Ghp8uEA0cCBqMLM0nt06+wuTTjurbTJ5xEuGF19rfZBNiZnPKj+5alP+glrrn UT1hAHLDKpcvTqNE4YcZU3/OpoOBMzbx1H+B5J0O+TMzVnweUl5taHvvkXOFLYICK8YL NqKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712564379; x=1713169179; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AX5+jXHMJTfU3cppVGB1oM10Q5k8KJr3dApT/VnvvYU=; b=oOU+dVe5lSTFe6JndNJZlvFO33fHyJwZOloeIWeiL0c+gPin1pvM+iXE/fKdeMhNxw 1ayqGh8FsCYV4k0IApD8r5EGMAyTUDQEcnWzQWEpRZG6NqOsD504IkZ9lgpyOPBk9iVc KofAif5IOXuYMgUs28vIkHBjoZA2v9GQrNel+ATyD2iiTIC262X8oXu517Ohd+g+rtXz xcKGkrNC0mbsQ0wJJ2TpQE3Kpu+ne5DHtXjuAbvQPVzdS8pdED6CgcGkeG96dSWwvEkT P5Dt7tEz93vRTEoeG7K7d3RqIe9pOHmQ0aDKpthzLZrc1j11rjx5CcppGoVh71TYI5IH zYHg== X-Forwarded-Encrypted: i=1; AJvYcCX93t10+/TvTYfRr5UYxI8sk42f/JnRj38v4t1GGr75EyDJXCIij2IMKcuaIEaVx2iLbV2+Wz0Wc5kkuN5OkGAdLH4= X-Gm-Message-State: AOJu0Yx4TDaOjHunFVT34OMbzj1b3xk+ry/q1UoBu+hk6nBTsKW5Nh7L J3lbZphLF8sAlLzdBzitub7YJBlrgULwjx/QjEAOYAOXWrX1azLi7S/dvN+WYUlV2MpPWyNSBwS KmoTcyVYF61w8X9jLj1dG9fhoSKQ= X-Google-Smtp-Source: AGHT+IHwKABiDH+sg4ocAOFV1rysPCy6M6jUel2pd3ftK4+6+b2hwxv91016VKyxPctK/xPT3DR2sG4D7Wn8cgcCrtA= X-Received: by 2002:a05:6102:32c8:b0:47a:110:143e with SMTP id o8-20020a05610232c800b0047a0110143emr1628878vss.6.1712564378854; Mon, 08 Apr 2024 01:19:38 -0700 (PDT) MIME-Version: 1.0 References: <20240408080539.14282-1-liuhailong@oppo.com> In-Reply-To: <20240408080539.14282-1-liuhailong@oppo.com> From: Barry Song <21cnbao@gmail.com> Date: Mon, 8 Apr 2024 20:19:26 +1200 Message-ID: Subject: Re: [PATCH] mm: vmscan: do not skip CMA while LRU is full of CMA folios To: liuhailong@oppo.com Cc: akpm@linux-foundation.org, nathan@kernel.org, ndesaulniers@google.com, trix@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, surenb@google.com, zhaoyang.huang@unisoc.com, quic_charante@quicinc.com, yuzhao@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: omdoawy6use1ktd9ptpo5w5mzcukzzwa X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D962340012 X-HE-Tag: 1712564379-748699 X-HE-Meta: U2FsdGVkX1/u3so5o/5TbNkoUFO7wpaxcrkKRQOinXbWcJRrKhTCAQxfAJlGQHjdDBHt6MMTUD0ZUT0FZwij5q7sN6pJFK3KNgsm54kZuuzh97v3hZy1kPDCn44fF6K8pCYDhhjDoiImZXroBrhKV7x9S3sVlts1ryf0UXMMeMwPh0IBfHSXJr41aQRNRQD659xqPWt3WruBBqrtB3IhESz/7xusdg5meyyEEfwFyPmr5+l/2KwLAlyhZ1oT7jhnBBkzv3gNR8LLT2kAzo2xKWXk3KmxE+gTz4TdN2Ksd/tFk0FZHkJPV7Y7CvRxnW2LBjzCrlBTwMqWaeegBtOaqwSza8a54t5fKSgnsvlS688hZL8u+iidQ5+xxAuR4jq40HvVE2PUyjFLG4OTiFPuZg0XB2a9AXXaf4vc+THceBKbccUKWiEVzi1Alj5ZxLYMgvNMG4vpPifGJb7a22HK4F7xlOVoouEeo5RH+wKVywO2BEDc15rWmVpqWh8mr7puWbT/majlY6JuGOPd5xzTuXS5agu4RAF1aK3tpB3OSL2HyCaUAgyj1KBLQhNvrwewgSeZ1rXESRkZlxvkQUximMnZQaegi7uBxkQMjIoT2P/4K1qDwvLCoXsKPEa0InV0DvB7LCse4a18bUzmsKS2TCMJC1R+L6adBM6LbErfwUyfUfCc8nRDr1jhq2YH7hU49nkQdN+2AGlyZTmiZ5KRzbpER1FuChWwI3HgT0oaGc/9f+ikf1FMH/DTZo0r3oJuhJ64hQy0WZT06rZ7Mi68ei4KrBzt3MPkKH0khU3V0HZOlk7G7pCkRXIWhzBNEOVbWACjOrKvGoJsZV3iovzTJU7sGZBiuRontiLcV9KrfwyDMvV4e8Bsca76K4pMciRHh4ErhlKInrVDH2SGA27iAOtuaGXOxri6aYRLDHCoEWIY+H7cP40+Fp2bm9ztq58vUKVq9RjR4zYWqzd+5J0 QYHOhlKT 5tMlqDzPRuG2CakUqcPV43ZjgG7zYPqJ1TN+ZwL/xsm+voC5tjbNk8IdjTgC14vz3pI7baujWX4wnVMI/X3A7N+c7tVjt6tWkenooYzVdYzOiNY5GoE+Vi0uogztw1vrD8Xeswl8F/t+R77DfhZZzQN0mgz1u97ZEj6p333W/tNJXxD6p8TR+QkUL6TIKEf7R3pIr0ln0YNvR61DHZbPDCNRA2p9JIcNnZsRAn+HPaDscspgzRVvKUBbrSYP/d4YHqrsGXsnci+gllFfoAcgXqzx86MLSAU5YV14KD3Pc1SoVXyDZ62Q00SLF/Ejrr55hdrxDuQuwnrv1WpW5yVe4OXRjM7v9QOcu0fXknfRFxrzMVxtjS82XWCMM40vz9njrOfuZyj1BwyuzgrZQ+lglMqGa9f4s9ghRM21Fsb+UrPiIcZE7tGvei+eF21U2qoX6rFsgooRyQUXALw3Ij1goo5nbxd8Kfb9MpD3W2EJosWmKH7xEdprNyaKTGA== 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: List-Subscribe: List-Unsubscribe: On Mon, Apr 8, 2024 at 8:06=E2=80=AFPM wrote: > > From: liuhailong > > If the allocation flag isn't movable, commit 5da226dbfce3 ("mm: > skip CMA pages when they are not available") skips CMA during direct > reclamation. This generally speeds up the reclamation of non-movable > folios. However, in scenarios with limited system memory and a majority > of reclaimable folios in LRU being from CMA, this can result in prolonged > idle loops where the system reclaims nothing but consumes CPU. > > I traced the process of a thread entering direct reclamation, > and printed the relevant information of the sc(scan_control). > __alloc_pages_direct_reclaim start > sc->priority:9 sc->nr_skipped_cma:32208 sc->nr_scanned:36 sc->nr_reclai= med:3 > sc->priority:8 sc->nr_skipped_cma:32199 sc->nr_scanned:69 sc->nr_reclai= med:3 > sc->priority:7 sc->nr_skipped_cma:198405 sc->nr_scanned:121 sc->nr_reclai= med:3 > sc->priority:6 sc->nr_skipped_cma:236713 sc->nr_scanned:147 sc->nr_reclai= med:3 > sc->priority:5 sc->nr_skipped_cma:708209 sc->nr_scanned:379 sc->nr_reclai= med:3 > sc->priority:4 sc->nr_skipped_cma:785537 sc->nr_scanned:646 sc->nr_reclai= med:3 > __alloc_pages_direct_reclaim end duration 3356ms > > Continuously skipping CMA even when the LRU is filled with CMA > folios can also result in lmkd failing to terminate processes. The > duration of psi_memstall (measured from the exit to the entry of > __alloc_pages_direct_reclaim) becomes excessively long, lasting for > example a couple of seconds. Consequently, lmkd fails to awaken and > terminate processes promptly. If you're planning to send a newer version, it's best to include the reproducer here. > > This patch introduces no_skip_cma and sets it to true when the number of > skipped CMA folios is excessively high. It offers two benefits: Rather > than wasting time in idle loops, it's better to assist other threads in > reclaiming some folios; This shortens the duration of psi_memstall and > ensures timely activation of lmkd within a few milliseconds. > > Signed-off-by: liuhailong I believe this patch tackles a niche scenario where CMA is configured to be large. Acked-by: Barry Song > --- This is evidently version 3 of your previous patch titled "[PATCH v2] Rever= t " mm: skip CMA pages when they are not available".[1] It's advisable to provide a brief explanation of the changes made from v2 and include a link to v2 here. [1] https://lore.kernel.org/linux-mm/CAGsJ_4wD-NiquhnhK_6TGEF4reTGO9pVNGyYB= nYZ1inVFc40WQ@mail.gmail.com/ > mm/vmscan.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index fa321c125099..2c74c1c94d88 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -114,6 +114,9 @@ struct scan_control { > /* Proactive reclaim invoked by userspace through memory.reclaim = */ > unsigned int proactive:1; > > + /* Can reclaim skip cma pages */ > + unsigned int no_skip_cma:1; > + > /* > * Cgroup memory below memory.low is protected as long as we > * don't threaten to OOM. If any cgroup is reclaimed at > @@ -157,6 +160,9 @@ struct scan_control { > /* Number of pages freed so far during a call to shrink_zones() *= / > unsigned long nr_reclaimed; > > + /* Number of cma-pages skipped so far during a call to shrink_zon= es() */ > + unsigned long nr_skipped_cma; > + > struct { > unsigned int dirty; > unsigned int unqueued_dirty; > @@ -1572,9 +1578,13 @@ static __always_inline void update_lru_sizes(struc= t lruvec *lruvec, > */ > static bool skip_cma(struct folio *folio, struct scan_control *sc) > { > - return !current_is_kswapd() && > + bool ret =3D !current_is_kswapd() && !sc->no_skip_cma && > gfp_migratetype(sc->gfp_mask) !=3D MIGRATE_MOVABL= E && > folio_migratetype(folio) =3D=3D MIGRATE_CMA; > + > + if (ret) > + sc->nr_skipped_cma +=3D folio_nr_pages(folio); > + return ret; > } > #else > static bool skip_cma(struct folio *folio, struct scan_control *sc) > @@ -6188,6 +6198,7 @@ static unsigned long do_try_to_free_pages(struct zo= nelist *zonelist, > vmpressure_prio(sc->gfp_mask, sc->target_mem_cgro= up, > sc->priority); > sc->nr_scanned =3D 0; > + sc->nr_skipped_cma =3D 0; > shrink_zones(zonelist, sc); > > if (sc->nr_reclaimed >=3D sc->nr_to_reclaim) > @@ -6202,6 +6213,16 @@ static unsigned long do_try_to_free_pages(struct z= onelist *zonelist, > */ > if (sc->priority < DEF_PRIORITY - 2) > sc->may_writepage =3D 1; > + > + /* > + * If we're getting trouble reclaiming non-cma pages and > + * currently a substantial number of CMA pages on LRU, > + * start reclaiming cma pages to alleviate other threads > + * and decrease lru size. > + */ > + if (sc->priority < DEF_PRIORITY - 2 && > + sc->nr_scanned < (sc->nr_skipped_cma >> 3)) > + sc->no_skip_cma =3D 1; > } while (--sc->priority >=3D 0); > > last_pgdat =3D NULL; > -- > 2.36.1 > Thanks Barry