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 968C0CF9C6C for ; Mon, 23 Sep 2024 01:44:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 020526B0085; Sun, 22 Sep 2024 21:44:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEBC36B0088; Sun, 22 Sep 2024 21:44:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D661F6B0089; Sun, 22 Sep 2024 21:44:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B5E246B0085 for ; Sun, 22 Sep 2024 21:44:31 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3BC2880FB4 for ; Mon, 23 Sep 2024 01:44:31 +0000 (UTC) X-FDA: 82594308342.13.5F3010E Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by imf17.hostedemail.com (Postfix) with ESMTP id 7A5E240002 for ; Mon, 23 Sep 2024 01:44:28 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="YtF6KL/v"; spf=pass (imf17.hostedemail.com: domain of jingxiangzeng.cas@gmail.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=jingxiangzeng.cas@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727055712; 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=pCLAeT+5noF4UxAMDA+O3X9/Yxx/NTQ52fWdyh16Ba8=; b=0LospNp2KHkE44Esc5jM74MoYqJ6esK+LjUaYPt2H9xLHmgbFov4Wlx4Re2vwvMASTV5Xh h87A0XRtvmxFI1MvkY8/KiCag0/KICTYQ1Ngo+57VyDiPHYYwoJ0Rvac1OMh83pDSIQZjg v+Dh+mD/eC15IQUOMx5s1KfT4u/TEzM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="YtF6KL/v"; spf=pass (imf17.hostedemail.com: domain of jingxiangzeng.cas@gmail.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=jingxiangzeng.cas@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727055712; a=rsa-sha256; cv=none; b=bjZWBYla/gm7YpSf0cE33bBIn9F3QpqUnFBxFuyR/oTDWGQsGWIewrC3NEvkXNnEhfb2Gg C0jRSF7zwmGPTjFPnzDF8YL57eD1ezbBY6ttFn5t/QON/XG6txQ74VIsypKTXp6PYRAPU5 llHlAZQHN0kWkfNqDbA7AfoAHRCl0FQ= Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-7191df6b5f5so2336524b3a.0 for ; Sun, 22 Sep 2024 18:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727055867; x=1727660667; 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=pCLAeT+5noF4UxAMDA+O3X9/Yxx/NTQ52fWdyh16Ba8=; b=YtF6KL/v559YYkkCAJbVsU0Bq4EuDClEm3gqQj3MQBAwUWKm3bNCepiq4+FlHYeBV8 L9Dax5TvpgzkX3j+ffY0IPbrXvT6HvAahtcZTND9AZhmVF5pdOGj/eO8+zpqkddZvUpM zXLVHF4UY5hHm0whT1v96QahCMsLEhimp59wGkB6kN/0wUdoPCawIEU4zVmJQw8PZGpt yW5CWwHoJFIbYhy+CUx0Kuhi0DYmwlQ0KvtBPcfv49yLsnsSpqMKJp5ER32t/jr7P5II 973NN6hkGPtlyXPCR97gMrmfHxtEBRymMM7gTFuCe+uVUVoIx9japLL08WrMNS7sYMSJ qWEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727055867; x=1727660667; 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=pCLAeT+5noF4UxAMDA+O3X9/Yxx/NTQ52fWdyh16Ba8=; b=Va33fnJAzELemXL4V80cveR6i7KAAtn75UeU1lg18hsQY3KrK8CvslzXYo5LRMWBNM O6EfGPM5nSCZIzSGuRZIJnnyZY5vwex7nqVnYD/TKvEM15zHZ5JxPYrCeeBk5CTl+P3C hvQqt5e0YY0f79eVTqzMrNeBparOVwtS96AJlgrehjVLlcoqZmHLvHaBfy48kSTl0Ehg SH4+PKpqO7NksDXXyG31OpqzaQY9D8S+b20QiHC+zbTMzQgWLAmNQ5OwXBp28qtOZurG tkiJYLJtX+ZQYqmdCMtjmuQYKf3ZUev6++I8i47s4KVcb/myCVjM6KOxzEgB13rUCcrF iagw== X-Gm-Message-State: AOJu0YzCQftnXGH7xgeUPM2kJhSVs4g7CXRLwJfzdiRG+Mk/leoDbb3G dXLPsQPC2KWmAA/63SdBziNAFA+DIzqbiZ8wieGlso9CWauP6WbKpsFxxBlxdF5DGzIRtvDwqzr rw/DL9n2hYIwBJP7vxGtJsMc3uSc= X-Google-Smtp-Source: AGHT+IGxmt0c8PI3xrSQR81j4QSBN73PfD0BZf96G0D8xZn6yTvd913qjysMV7JOpfiJJH/v9IBFlbxbPxVPzuI4IzM= X-Received: by 2002:a05:6a00:c90:b0:710:6f54:bc9c with SMTP id d2e1a72fcca58-7199cd7a3b1mr13644469b3a.2.1727055866966; Sun, 22 Sep 2024 18:44:26 -0700 (PDT) MIME-Version: 1.0 References: <20240913084506.3606292-1-jingxiangzeng.cas@gmail.com> In-Reply-To: From: jingxiang zeng Date: Mon, 23 Sep 2024 09:44:15 +0800 Message-ID: Subject: Re: [PATCH V2] mm/vmscan: wake up flushers conditionally to avoid cgroup OOM To: Wei Xu Cc: linux-mm@kvack.org, akpm@linux-foundation.org, kasong@tencent.com, linuszeng@tencent.com, linux-kernel@vger.kernel.org, tjmercier@google.com, yuzhao@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7A5E240002 X-Stat-Signature: pnbh97ary48snm856q1ux99nf7zp45hw X-Rspam-User: X-HE-Tag: 1727055868-140727 X-HE-Meta: U2FsdGVkX1/iqpg7g3gPeii7QIM+4r5s0sUbYO0VCuNbA9wtjZAickOgZzAYvTnDBBxTPW5atvkSHfIG5GO1Ts/GXBU3dTQXZ//Y4kCBnDox0wQYJBRTpbckyDW0xd2iTH53cbOaKFJwJxgkbcKuV9TQw7OyCE/0BNGQtavWxAJbMcS9h6CwFzo/aLYmpUNIxsDmqCHve+jva+019UyIBxVHMT3ZsNfMvpcUQfNjgvpMBJKAY8r0wpYEN8scaaBwF6V3H9jJ3QYtIZpgG8X2hAGYKxWyxt1fSZSOsWAS4JijeFla0CAnu2+G6CrsyX+rzxx3aIBpG+hUsT0gJhqHS6n/1jvAR+5cWrHKd9aUTRiPEfSW0Zn2NlufNOVawzjTt0DJrz2hVf09yCXvbdMCTmXdmfXVPHZSJ+CHH/pe0vFrt17u4IEwsLkiR8n0uDahMI1G6cv6m0PCtll3fcvwpo/DmsGbNs7Q765+SATFU8QMpVLToYlgghzvfAp143NoB4uujR75fvG6WR64bXsEOosxp+LxphiIVJURc/5FQhNSUTbBe4fpEQxvw2yGwmzqkp/jXLBCqptjJU5FfFsGdZcPwRzfI/0a2J1hdjA+E9jcM7cXOO6ZS9iseEtX5zhWD+RHid+9S3N3/5bd8E/X/8BCjsQKN0928aR6GGVhF5m4U181rIeG9fF6h4nH/Ia6dM/7i6pteF2NJi91tO3muvz86J6UZP099FjA+qlMc4Coz1z82llD4nZ7drLrFCWweesMPJph8uNfu7TN/6AMD/5seZTUi/SWSL6RLn4XFWWaaskzip1BdwBP4C3VJ3c13In/rvDONB1jkwLwg3DEZXCaHsU3gbMhu7N5ZLucfqguKCdBP3EI1QbQZDKwH6cY5VonF4uq7bIioQCuXDsrT7hm7/oa/emUa8Bl7SQmUJ+KbSaX4S58tELVV2zbTzj1qVIjlb+NvurBsLl5FkL BqeePeqR 7iLEQU13G4b8DNCTuh8/98w0hOMVQlegtVKENpk2qaXuaVp1ClUukz8rF6fAp4PMpHpEMXN8oEIjmRncc6AxAle6N2UyRH7UtDS/2VliBtp4rK5KpjBtFItSDW4Ofq0BH8IAXZg4Rerxfxni3W+wm4rhjt7Jpj+qjj92nzb8h+zjA8h9GyteVv3ofsjmaY+6Em3oyaRnVGT+bBlEAWBZkegjgZru6J0Q6nD939+iycELDXRlwmI+y6cOsx08gJTZvV4nZ2GhDhBhqeVEDnrrTo45F3nSyEcrtDXqx6uI7I4qzM+rrHwDlgZYI3EGmVymqhMbsI1+1SB+hWKwcs2gUiBsozv+BdvLq1MDkQEldYqkAt4sMGiGK2Is+jiOEyTz2M+PbO3j3aYsi+dplgGyrxoZAJXbmFs48XNVSZ22xmTG6SlqfE/ke+FjihMtjvJ2Tps1KaoGOxe8oRWKmLClGrwfJRGYCO3890Rwh15PBRZdfdb8HoHcG4e0sN2Hug1i6BeWt 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 Tue, 17 Sept 2024 at 00:11, Wei Xu wrote: > > On Fri, Sep 13, 2024 at 1:45=E2=80=AFAM Jingxiang Zeng > wrote: > > > > From: Zeng Jingxiang > > > > Commit 14aa8b2d5c2e ("mm/mglru: don't sync disk for each aging cycle") > > removed the opportunity to wake up flushers during the MGLRU page > > reclamation process can lead to an increased likelihood of triggering O= OM > > when encountering many dirty pages during reclamation on MGLRU. > > > > This leads to premature OOM if there are too many dirty pages in cgroup= : > > Killed > > > > dd invoked oom-killer: gfp_mask=3D0x101cca(GFP_HIGHUSER_MOVABLE|__GFP_W= RITE), > > order=3D0, oom_score_adj=3D0 > > > > Call Trace: > > > > dump_stack_lvl+0x5f/0x80 > > dump_stack+0x14/0x20 > > dump_header+0x46/0x1b0 > > oom_kill_process+0x104/0x220 > > out_of_memory+0x112/0x5a0 > > mem_cgroup_out_of_memory+0x13b/0x150 > > try_charge_memcg+0x44f/0x5c0 > > charge_memcg+0x34/0x50 > > __mem_cgroup_charge+0x31/0x90 > > filemap_add_folio+0x4b/0xf0 > > __filemap_get_folio+0x1a4/0x5b0 > > ? srso_return_thunk+0x5/0x5f > > ? __block_commit_write+0x82/0xb0 > > ext4_da_write_begin+0xe5/0x270 > > generic_perform_write+0x134/0x2b0 > > ext4_buffered_write_iter+0x57/0xd0 > > ext4_file_write_iter+0x76/0x7d0 > > ? selinux_file_permission+0x119/0x150 > > ? srso_return_thunk+0x5/0x5f > > ? srso_return_thunk+0x5/0x5f > > vfs_write+0x30c/0x440 > > ksys_write+0x65/0xe0 > > __x64_sys_write+0x1e/0x30 > > x64_sys_call+0x11c2/0x1d50 > > do_syscall_64+0x47/0x110 > > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > > > memory: usage 308224kB, limit 308224kB, failcnt 2589 > > swap: usage 0kB, limit 9007199254740988kB, failcnt 0 > > > > ... > > file_dirty 303247360 > > file_writeback 0 > > ... > > > > oom-kill:constraint=3DCONSTRAINT_MEMCG,nodemask=3D(null),cpuset=3Dtest, > > mems_allowed=3D0,oom_memcg=3D/test,task_memcg=3D/test,task=3Ddd,pid=3D4= 404,uid=3D0 > > Memory cgroup out of memory: Killed process 4404 (dd) total-vm:10512kB, > > anon-rss:1152kB, file-rss:1824kB, shmem-rss:0kB, UID:0 pgtables:76kB > > oom_score_adj:0 > > > > The flusher wake up was removed to decrease SSD wearing, but if we are > > seeing all dirty folios at the tail of an LRU, not waking up the flushe= r > > could lead to thrashing easily. So wake it up when a mem cgroups is > > about to OOM due to dirty caches. > > > > Link: https://lkml.kernel.org/r/20240829102543.189453-1-jingxiangzeng.c= as@gmail.com > > Fixes: 14aa8b2d5c2e ("mm/mglru: don't sync disk for each aging cycle") > > Signed-off-by: Zeng Jingxiang > > Signed-off-by: Kairui Song > > Cc: T.J. Mercier > > Cc: Wei Xu > > Cc: Yu Zhao > > Signed-off-by: Andrew Morton > > --- > > mm/vmscan.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 749cdc110c74..ce471d686a88 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -4284,6 +4284,7 @@ static bool sort_folio(struct lruvec *lruvec, str= uct folio *folio, struct scan_c > > int tier_idx) > > { > > bool success; > > + bool dirty, writeback; > > int gen =3D folio_lru_gen(folio); > > int type =3D folio_is_file_lru(folio); > > int zone =3D folio_zonenum(folio); > > @@ -4332,6 +4333,9 @@ static bool sort_folio(struct lruvec *lruvec, str= uct folio *folio, struct scan_c > > /* waiting for writeback */ > > if (folio_test_locked(folio) || folio_test_writeback(folio) || > > (type =3D=3D LRU_GEN_FILE && folio_test_dirty(folio))) { > > + folio_check_dirty_writeback(folio, &dirty, &writeback); > > We cannot simply call folio_check_dirty_writeback() here because > folio_check_dirty_writeback() assumes that the folio is locked (e.g. > see buffer_check_dirty_writeback()). Thank you for your modification suggestion. > > > + if (dirty && !writeback) > > + sc->nr.unqueued_dirty +=3D delta; > > gen =3D folio_inc_gen(lruvec, folio, true); > > list_move(&folio->lru, &lrugen->folios[gen][type][zone]= ); > > return true; > > @@ -4448,6 +4452,7 @@ static int scan_folios(struct lruvec *lruvec, str= uct scan_control *sc, > > scanned, skipped, isolated, > > type ? LRU_INACTIVE_FILE : LRU_INACTIVE= _ANON); > > > > + sc->nr.taken +=3D isolated; > > /* > > * There might not be eligible folios due to reclaim_idx. Check= the > > * remaining to prevent livelock if it's not making progress. > > @@ -4920,6 +4925,14 @@ static void lru_gen_shrink_lruvec(struct lruvec = *lruvec, struct scan_control *sc > > if (try_to_shrink_lruvec(lruvec, sc)) > > lru_gen_rotate_memcg(lruvec, MEMCG_LRU_YOUNG); > > > > + /* > > + * If too many pages failed to evict due to page being dirty, > > + * memory pressure have pushed dirty pages to oldest gen, > > + * wake up flusher. > > + */ > > + if (sc->nr.unqueued_dirty > sc->nr.taken) > > + wakeup_flusher_threads(WB_REASON_VMSCAN); > > + > > The wakeups will be much more often than intended because > sc->nr.unqueued_dirty includes the drity file pages now, but > sc->nr.taken doesn't. When the scan_folios function scans the coldest generation, when the number of pages that need to be promoted due to unqueued dirty pages is greater than the number of pages that can be isolated, the logic here will wake up the flusher thread. This condition will indeed be triggered when there are too many pages in the coldest generation that cannot be isolated. I think this condition for triggering the flusher to wake up is reasonable. Are there any other good trigger conditions? > > > clear_mm_walk(); > > > > blk_finish_plug(&plug); > > -- > > 2.43.5 > >