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 C6261C54E60 for ; Sun, 17 Mar 2024 05:47:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF7456B0082; Sun, 17 Mar 2024 01:47:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA6B76B0083; Sun, 17 Mar 2024 01:47:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6E7E6B0085; Sun, 17 Mar 2024 01:47:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B667D6B0082 for ; Sun, 17 Mar 2024 01:47:56 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 34ADDA0F09 for ; Sun, 17 Mar 2024 05:47:56 +0000 (UTC) X-FDA: 81905449752.05.A405DA3 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf20.hostedemail.com (Postfix) with ESMTP id 709971C0009 for ; Sun, 17 Mar 2024 05:47:54 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CBBb9gGr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710654474; a=rsa-sha256; cv=none; b=CXu25r/obeyeHigeJ0KH4WGV1tOWCJszi+bWMHznS5uRxmhTCKoh6vJjRyHWv8gxS96793 WOacEfFyg71xPsZOFOVYCQt++62WQNXs90WJ9vMuUIaI/3Mi14oiLhaHHQ5FSXXpcaeRUD ObGHIN31bTyXZhFkASWgdGjv/2hQs+0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CBBb9gGr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.160.181 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=1710654474; 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=ZjI0CmTAb9rBKNzvuDpGMzLCdPan9spH7TYPxSq//7M=; b=QyLZANwkLjNHjsjDYj0wxH0sIC2vXIQsCa7d9fkSqPFIbtQ0p8wsIwms4BX0r8oYfmhW2u acJMD6DvvcL6NSSY/ctChDcIE5nLUQfki285TUiO7bY5Dncix53QwTv4wf8T5uIX8cvD8W chm8LFsmbHTAk5KxuLWRvin74PQXmTw= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-42a029c8e76so25286111cf.2 for ; Sat, 16 Mar 2024 22:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710654473; x=1711259273; 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=ZjI0CmTAb9rBKNzvuDpGMzLCdPan9spH7TYPxSq//7M=; b=CBBb9gGrd96WNWIX3L9hIe+wfbj7UKwjL4IUy+BWC9spU7hGWXiFFO+Ifk4vtDFO5w EH7PV1rXwNqVz+nXVjDEH+TBibute3yrOZKdjoz62JMqjQCIsc7md0TJZNZPGs5f6Ax6 Uo+78aS+W045BGuRAzWyLtsTq9IJPwx8T23WbVpmsWv58KA9+hDycnmkGbbD+gv7QiM5 x4pR+7SrRhIKWh5WLaqoNkjrVTuaTl/HYEOdmYvzFU2kJEcru/qlZyb5yTbsDkkOa0M/ 7LcWl1HCCGFgJdIKY+bmVJxEHVucmOHEldlQxjhnAiZt956MaW8rtO7hnBCJYd2skje7 Tp9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710654473; x=1711259273; 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=ZjI0CmTAb9rBKNzvuDpGMzLCdPan9spH7TYPxSq//7M=; b=wO/n2aflmvAoWrLAW9ZTdYIAE5EAHXs+nE2jMaDzAvg8RlzaT/K7o4K3i7bC10if2j 0tPV+TsXJ0VIHlqNEtrp6wj2WDA2rhyfYfEvvrjEENEu13AHEtqvxDKH5S8+TvtE2Dcu cpmSDum2L8Q9bzUyfRtHPqGsdMlCOpV617UwrdJ7VoXRkkpdLw7WvQtFo6qBHvkUnkyN WdKvTSwwczRMI2Q8hsPumtWXQu4mydUiC57irDkWoWQ7rDrw7Lhlyo64icgBcKmgdwxi blhzGbhc8oDML5GgQytj0tF/ou83/5l93WBJXKMSG2QrRD1ZZlxzmkqj0iHUrApsEqEE uDmQ== X-Forwarded-Encrypted: i=1; AJvYcCUMFQlyeL2EByrHuVrFhZ5YP9dktw8jAVLuSvOmF1knCUqIUIqc2upa0RGw/yW7t75O+IOXOPktJo4WhT2kOUNe0Ww= X-Gm-Message-State: AOJu0YwJyLjfHdx5ZdQUqdyOn7kr7QQHmodaSRd6XXtKK4tQ8ZoRIAwW 1Uh5rxCq5qCKYPjO2wNqs+CHPuX9pAdwcWioNNiZtt8fjhST0/R4mIqD4xyZEEBqqrRmiey/kso LUIg0As+h0dDeMUCIoQekjDWOAv8= X-Google-Smtp-Source: AGHT+IF3n6ILrbIcqyw7Dk9ldN+JFXuDe2uBcHpys1fbj9TlKl6rn+Ktc0cERNyAszqG9dMbRhcxpRA2dK4IuomqNow= X-Received: by 2002:a05:622a:1cf:b0:42e:eb29:91ba with SMTP id t15-20020a05622a01cf00b0042eeb2991bamr11260429qtw.63.1710654473492; Sat, 16 Mar 2024 22:47:53 -0700 (PDT) MIME-Version: 1.0 References: <20240314141516.31747-1-liuhailong@oppo.com> <20240315081803.2223-1-liuhailong@oppo.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sun, 17 Mar 2024 18:47:42 +1300 Message-ID: Subject: Re: [PATCH v2] Revert "mm: skip CMA pages when they are not available" To: =?UTF-8?B?5YiY5rW36b6ZKExhb0xpdSk=?= 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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 709971C0009 X-Stat-Signature: sy5jaq4bjjz3jskte1ggygprtmc7y5hu X-HE-Tag: 1710654474-510053 X-HE-Meta: U2FsdGVkX1+TyXZuvY8z0xDKW38+t4lz0JNhgantqOUZ65RohLAVlahrYLh/QZ75agLJbnxWSjFKHN+TYBLnDIyzeI9UBkYjSgcSzEG2HwexZ+qIBjvZQuAd+1BbH1LzO9OpUSg8I4CmmZvqH0GRiVbOFTz/hjPzcO2zUjPR4Ec41dC/3bdaCSoHqMDxo1qtRNdC/XIOEbfEbLEvmYUs3LcRgMOZdvMrSo/xZcYRN4LeP6n1LTeySLKW2YVJW6ltAw/2qck1SKubOZkFVLwmeykWh8g7Fp5sSY/Z8psaWf2iJr8K+AqbrMsEc8bYIK7ccW0vuU2UvJSaJ943QrICb8Wmz0SPqeMCW89PttsnfsLcCf7GKq/JI/TlFec0XV5niyOGFzRR6oqbVfItmmQUYbL4SNl3uDFw4xgI3KOdY70ENlWgpn/WOdrCUkD6DjOHEqx3d3OtHpJjh514lDtmdsQQqALrUQQxghhAdZS0hc4oHsuoQshvag73qh0mZASFFFDfmRWaYP6362JAkn6yzNXGLaoRM32TySZnebceePO0DdvchGdsLy9w9aLrkBycgu+JiD+SQ3Ieb1izNXvyZOeya/AHo5MFgrE1quikWyquhSov0WMuRLtogRNxmkv/qqkgnkZTlXOPlZgOU86bne0tOuimyk8V4xgH0MPzNW+3PtFtY3Ob4Qk+g4kQNxp90B6yEDN407o9tGMTzuLpeBDznMk75lBk+UJVOk4IvqigByCwfAOAZ9cGUuKxs3BFLy8s1aNZLsEjIFkMrCJKPQr8O3Ia/CyDBrroklVegNfYarQmaHIwCyXMkPTh/j5PbV5uEGmpaNw8Da7MMuWw106M+aIS2jFhX5BZn8KJjqRxSPSflKtUcsHpS1CmHsgFSHLNwAL665xc5bnsAOUchZ7DXpScS7f7wek7SaL5JDXhZ9J0g+GzZIiTaGhj9pKDPWM7uDm8x3xxY2l2Bfu CH3SnSIB KYSI3Sb8AsdZQd438jdMCsrgfgvb3X+4/xZd2nLxXZScicoZmHhUrDWOjMLesVWDlSK6/LDXrnh/ZkDj7HcrVZLVZt6uR3qHlsur0PnO/XDeF7E8ODMeJicU4bKVQhgfKZED1mEpeP3LBNwNI833PXYp68T0Nu29jhf/9IZpaFwb9//EiCr/qeTSb8010EhclcdbQb2mplCTqqldreh6yU2n8FDMRB2j0+KlXwKWCy+37bqGxaxjsIdTjwW3rMsIFnHEpzZmLxWBzrw/2jL/laimeR8XPyzXFHRjRJCK48I7ysdnl9fm3qRd/83c2whNUlD7etqlZJqFWRKx6A9fCySjy5Q/JPClsYWGf8Jn2h3b3ysPm/6YMM5bLL3PZdm+QS1yurLJ/03AyTiFwilKjOU2tWJytUruDutUxm9Cq/Ltabbv6w+OC/FfoM+/Ux7nk6DqiSEXayhRcP94= 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 Fri, Mar 15, 2024 at 11:44=E2=80=AFPM =E5=88=98=E6=B5=B7=E9=BE=99(LaoLiu= ) wrote: > > On 2024/3/15 16:46, Barry Song wrote: > > On Fri, Mar 15, 2024 at 9:18=E2=80=AFPM wrote: > >> > >> From: "Hailong.Liu" > >> > >> This reverts > >> commit b7108d66318a ("Multi-gen LRU: skip CMA pages when they are not = eligible") > >> commit 5da226dbfce3 ("mm: skip CMA pages when they are not available") > > > > Reverting these changes seems inappropriate since the original patches > > did improve most cases. > > While doing direct reclamation without MOVABLE flags, scanning cma > > folio doesn't help at all. > > > > Absolutely, but without this patch it give chance to reclaim cma pages t= o freelist, > other tasks without this flag would work normally without holding too muc= h time > on lru lock and lru size decrease=E3=80=82 it also trigger memory psi eve= nt to allow > admin do something to release memory. > > >> > >> skip_cma may cause system not responding. if cma pages is large in lru= _list > >> and system is in lowmemory, many tasks would direct reclaim and waste > >> cpu time to isolate_lru_pages and return. > >> > >> Test this patch on android-5.15 8G device > >> reproducer: > >> - cma_declare_contiguous 3G pages > >> - set /proc/sys/vm/swappiness 0 to enable direct_reclaim reclaim file > >> only. > >> - run a memleak process in userspace > > > > > > I assume that scanning cma folio provides additional opportunities to r= eclaim > > anonymous memory, even though it is ineffective for allocating NON-MOVA= BLE > > folios. Consequently, we alleviate pressure for future allocations of a= nonymous > > folios. Moreover, setting swappiness=3D0 is a rare scenario. Instead of= entirely > > removing the mechanism, could we detect such corner cases and handle th= em > > differently. > > > > Otherwise, I don't see any chance of this being acknowledged. > > It happens in internal aging test. open camera and record 8K video which = use > more than 2Gib dmabuf pages. without this patch the devices would kill ca= mera process, > but the system hang with it. > > In fact, in my opinion the issue of this patch increase the scanning lru = time > and reclaim nothing. Do you have a better solution ? rather than aggressively reverting the original patch which might help lots= of cases, could we just detect the corner cases and fix them , for example, by something as the belows, diff --git a/mm/vmscan.c b/mm/vmscan.c index 96147c4536e4..2f75ad9870c1 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -147,6 +147,9 @@ struct scan_control { /* Always discard instead of demoting to lower tier memory */ unsigned int no_demotion:1; + /* no skipping cma */ + unsigned int no_skip_cma:1; + /* Allocation order */ s8 order; @@ -1595,7 +1598,7 @@ static __always_inline void update_lru_sizes(struct lruvec *lruvec, */ static bool skip_cma(struct folio *folio, struct scan_control *sc) { - return !current_is_kswapd() && + return !current_is_kswapd() && !sc->no_skip_cma && gfp_migratetype(sc->gfp_mask) !=3D MIGRATE_MOVABLE = && folio_migratetype(folio) =3D=3D MIGRATE_CMA; } @@ -1636,7 +1639,7 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan, unsigned long nr_taken =3D 0; unsigned long nr_zone_taken[MAX_NR_ZONES] =3D { 0 }; unsigned long nr_skipped[MAX_NR_ZONES] =3D { 0, }; - unsigned long skipped =3D 0; + unsigned long skipped =3D 0, skipped_cma =3D 0; unsigned long scan, total_scan, nr_pages; LIST_HEAD(folios_skipped); @@ -1645,6 +1648,7 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan, while (scan < nr_to_scan && !list_empty(src)) { struct list_head *move_to =3D src; struct folio *folio; + bool cma =3D false; folio =3D lru_to_folio(src); prefetchw_prev_lru_folio(folio, src, flags); @@ -1652,10 +1656,11 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan, nr_pages =3D folio_nr_pages(folio); total_scan +=3D nr_pages; - if (folio_zonenum(folio) > sc->reclaim_idx || - skip_cma(folio, sc)) { + cma =3D skip_cma(folio, sc); + if (folio_zonenum(folio) > sc->reclaim_idx || cma) { nr_skipped[folio_zonenum(folio)] +=3D nr_pages; move_to =3D &folios_skipped; + skipped_cma +=3D nr_pages; goto move; } @@ -1716,6 +1721,16 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan, *nr_scanned =3D total_scan; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, total_scan, skipped, nr_taken, lru); + + /* + * If the majority of folios are skipped due to contiguous memory allocator (CMA), + * the least recently used (LRU) list might become overloaded with CMA folios. + * This could result in numerous idle loops for non-movable allocations. On the + * other hand, reclaiming CMA folios can alleviate the strain on other processes + * that require anonymous pages. + */ + sc->no_skip_cma =3D skipped_cma > total_scan / 2 ? 1 : 0; + update_lru_sizes(lruvec, lru, nr_zone_taken); return nr_taken; } This is merely a proof of concept (PoC), and I haven't even built it yet. Additionally, LRU_GEN remains unchanged. It will also need similar changes. > > Brs, > Hailong. Thanks Barry