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 A3221C5472D for ; Tue, 27 Aug 2024 02:45:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 378646B0083; Mon, 26 Aug 2024 22:45:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 328676B0085; Mon, 26 Aug 2024 22:45:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CA216B0088; Mon, 26 Aug 2024 22:45:29 -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 E57B46B0083 for ; Mon, 26 Aug 2024 22:45:28 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 947E741588 for ; Tue, 27 Aug 2024 02:45:28 +0000 (UTC) X-FDA: 82496484336.22.20EFE75 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf28.hostedemail.com (Postfix) with ESMTP id B16EFC0015 for ; Tue, 27 Aug 2024 02:45:25 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kA2rYFlq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724726662; a=rsa-sha256; cv=none; b=NMbiUxwzlEvQaxxmpI4VABJw08SpVx3zLWgNqa11mgFsHAv6nSk+u8yTgw8vygEgk8R+PP mz+8KvoPJTCgukhi3JKimZiQZ/n8efcxu6e8rvIHNjM/QXtfWJJ2K4ELfCKST1wqnvyq5c F1H+MqfFPViAponwrrgTXUaVVGKr7mI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kA2rYFlq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724726662; 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=odo7MA1BwB4xl/JpztclR0wYGRn7j5laIM/t5K3583o=; b=lHX2EhoPgD9Mfw1ZYgazbTsmoaoCesO5baoM4xid82ixFFqw9T0GWRVyVpCUDI/SruobQL wWtWSIIjHxQKNRIM783Fs6z/d/QaYl8eF/wBoz1+3X/dwnyYerFOGSrz+TYTbVYQOgIkWh CnNhOklDHRsY3tpg/d6F8gFLnrYQi6k= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-5334eec7485so905470e87.3 for ; Mon, 26 Aug 2024 19:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724726724; x=1725331524; 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=odo7MA1BwB4xl/JpztclR0wYGRn7j5laIM/t5K3583o=; b=kA2rYFlqIgyRMlMK7PhEoighakZnLj+9auG68A3bbvN19ocRza72B+rVtm4MkJFNMq dalybBCDrRBMPETzk8OAV60EeG/dteiWG29JlB1RbGi39XqaSWwTfeEr2aUulsl1HHYk 23TOhT1AxwleP9VQlGgqVkARnZqdIjfG0GpAXWmD/oZLzDzvp5VVbwl3gkheMagcDcqX zU1LNpzBUpKW5WLHRnfyo8vJSbQa64xUO977n3PAQeG0F9w3yf8OOA7opUHAlHzsiFhL WUUeDSPkjQpBtPd60gN1NyN/Qne8a+Dno430+vDykj0V1CycFhoi0tCVvB9IpcCIPwj+ 9Zdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724726724; x=1725331524; 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=odo7MA1BwB4xl/JpztclR0wYGRn7j5laIM/t5K3583o=; b=CiS7EOoU3U5O4tyFKFwwxLb7h0Xfzw8hvpu10JOlztNoY4P2PxiqRaegwl/OuRIJ36 6RskfTZBakzRDbVMRJk+3polnnNAd2uN8mAI500bEnnZ24iDFh896Xb5Ac3E7mpKTXrq HB4yT8LAL24yahNEcdTjIxsn2fvMiH2zhY513trrxaUk5TH7B9lHscYtbnVxpIsmkQID MGc3fR1HzQFVFbDq9+TKDyDaPC3LscfO7yq/2c/r3tyG6l/Xlaal59Nv5L/1wmB3/r74 Dw1KgIC1QDGf67f8nD+KmNiMlt7U+1Y9mw0rnr/BFm6qDDUspz5J5MMC0q5vV8uSe+a2 2E3A== X-Forwarded-Encrypted: i=1; AJvYcCW6l4OY7KxC8OQdaY+MPfOYJV+6M34NqQivt4TLQtE9yW3Ka4gzcx+OaxkMkNuVbm9xLjJtVrfong==@kvack.org X-Gm-Message-State: AOJu0YyopKlQKsUS83R11vUTjeDcKKnLUp8pK4dYZszf1GYV7gfQ7ZWT gjErChBwRI7/74ezahlFWzE9lXL/GpZkl0xhlN1yX9nWae5t0EJoeSuRQYFaxErBgv5tdvmr3OR TXRr3SSpJOj5miXo0UiDHCnrqOKM= X-Google-Smtp-Source: AGHT+IGhIWauwhd7CfTvEFefwc8UWS77qzcdEn+zCHcf96G4XgJBEy5KJcxkEborgkAAwtFQ1NTCtmRILC5pE2OoxsU= X-Received: by 2002:a05:6512:3b23:b0:533:793:e3d9 with SMTP id 2adb3069b0e04-5343876c282mr4498156e87.2.1724726722962; Mon, 26 Aug 2024 19:45:22 -0700 (PDT) MIME-Version: 1.0 References: <20240826085056.895865-1-zhaoyang.huang@unisoc.com> <38881e37-767c-456a-8301-2a7d0371d12e@redhat.com> <8ffc4e3f-bae9-4567-8eb7-f1b163309d7e@redhat.com> In-Reply-To: <8ffc4e3f-bae9-4567-8eb7-f1b163309d7e@redhat.com> From: Zhaoyang Huang Date: Tue, 27 Aug 2024 10:45:11 +0800 Message-ID: Subject: Re: [RFC PATCH 1/1] mm: Skip folio with private data during isolation To: David Hildenbrand Cc: "zhaoyang.huang" , Andrew Morton , Matthew Wilcox , Yu Zhao , Baolin Wang , linux-mm@kvack.org, steve.kang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B16EFC0015 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: dm6y5y8ri61b9m4nzb7h4ywzhs8fmjsb X-HE-Tag: 1724726725-416962 X-HE-Meta: U2FsdGVkX197LKGxW2t8Kly39o7q4M5eQ0DTtrEzAzTbc+LH5hUVXa0CXkIgqwz202B8E1R83v4jwTGn2lRje68xDj2sSlkY+qDv0DJExTuX+MKMPA9njZOFUopNCe/amDl+n2nUA955qncKKM8UgJtAsQXP0nYJShjwo6YLcDxud0Cq8Ub+9XnrD89l6dl2L1jDh0c/hTme0kbNQQdeV0y31hq0g846KW1rXUMAzZJRSk6ziyjxDBJcz0mEWbR+PfKL65qQGIVTKT7pzNB7Liinm+t4iYAFJqEoOv0gFhSgsAmIRMjyvOurxkXXqB9XVTiHtqlWCXzWg9jEGB/ycCq/aXUrziQFdjpk9/aoN/ILr0WZ7gVVFQ0UPaSbc7nqIWdVJxN383JJ87ko9IyROhufPkHZA+TgLSkx4mkTkYdd60DaR7kJ98gRPydYW8HSxxtb8nfuq2U4Dv1lAX7HgfdJyw7FfJwhD7hd4Xetar/aFhLMRS+wxvYhj1HXWgD8aYb+kl3FNDLnfnhXSRYPaGEFIxTK+ZeEjaZBWFEaU7KLp9VQKbMjkC4s0FDL8GexUE+jAG5IaGNoQiGzuYhG0QvGBvW/LAGKbGzPLd3leEzKc0CuNtURJicPSmcoBUb98n0SLkbJzvqUVXx9RqisEQvpyUQzkFtgzlnT+MT/bMtm3ZNH253hKLNNmCZjvnARl3vSBqxwWiVGZb0hdk+auhMbt3bTZylzJclrrVOKqmNAmAqCv7JS5SsdVR3D0v5PChFhlwLPsyy0VIh1KVT+H640o/AqU93LfzzpzWpSg2I98qqNgpvMZYQffHn4t1i0TefubIdZwPcFycbPy6WXFWERsNQ/5Q4NXMYvvptQ0+EUgF1pBi4rQ9lA2Ibr1GeZjNFb9xByiSymheBg+/DnFMhlwikhSLer6R45bExRMzXONMcPNOz+yAysgxAtjdlr2dz5OQofcj61QYEUzNH af5sEnS7 akIXebluy2LZQeJxiKeiwpaUJviN84OnECvDtIXVpz8JR0RbiQ1kGIRWBcmmQNPw85eOPxvMofrgD4cd7LwvsI4NZ0I+andQtPeYsMtK9n2fbndFyQ6WI6ufDrY1FHeY/gFwvoEzfOAxtzBJEETT7AbPFERe3MsRAj0r0Nh74uxM66E7r85Xuie+qK60ifpEpVCLkswy3ng0Nr7BOUJVj4xiN9LmZIPxYYTtvFJopC6JjLOHpT6FcPv9r72/LknLISd/6E+n3CkRdUAWx3eoMR1VU/fokGDDWsRo1askDDbLU3jdwS2fLqx43JSuApSkSBYfmJOaLgmb5RzR5QEK41/BF0yODBRACsMO6oTUXHF4lNsXE3U8irftC7pjRl62yIxnc 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, Aug 26, 2024 at 9:01=E2=80=AFPM David Hildenbrand wrote: > > On 26.08.24 13:10, Zhaoyang Huang wrote: > > On Mon, Aug 26, 2024 at 6:36=E2=80=AFPM David Hildenbrand wrote: > >> > >> On 26.08.24 10:50, zhaoyang.huang wrote: > >>> From: Zhaoyang Huang > >>> > >>> Since clean target folio with private data will be given up finally i= n > >>> __remove_mapping as it has extra refcnt, it is better to skip it duri= ng > >>> isolation to save the slot for more qualified folio. Current one coul= d > >>> be the candidate for next round of scanning after the private data go= ne. > >>> > >>> Signed-off-by: Zhaoyang Huang > >>> --- > >>> mm/vmscan.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/mm/vmscan.c b/mm/vmscan.c > >>> index cfa839284b92..755bf3a387f3 100644 > >>> --- a/mm/vmscan.c > >>> +++ b/mm/vmscan.c > >>> @@ -1685,6 +1685,8 @@ static unsigned long isolate_lru_folios(unsigne= d long nr_to_scan, > >>> */ > >>> scan +=3D nr_pages; > >>> > >>> + if (folio_test_private(folio) && !folio_test_dirty(foli= o)) > >>> + goto move; > >>> if (!folio_test_lru(folio)) > >>> goto move; > >>> if (!sc->may_unmap && folio_mapped(folio)) > >> > >> An earlier filemap_release_folio() would have failed if the private da= ta > >> (buffers) cannot get freed, and we went into the activate_locked path. > >> > >> > >> if (folio_needs_release(folio)) { > >> if (!filemap_release_folio(folio, sc->gfp_mask) > >> goto activate_locked; > >> ... > >> > >> if (folio_test_anon(folio) && !folio_test_swapbacked(folio)) { > >> ... > >> } else if (!mapping || !__remove_mapping(mapping, folio, true, > >> } > >> > >> At least on the shrink_folio_list() path, I'm not sure the code you ar= e > >> adding could even trigger. We should not reach __remove_mapping() with > >> folio_test_private(). > > Thanks for heads up. You are right, the bh is judged if existing > > before __remove_mapping. ASAIU, the metadata associated with the bh > > has risk to be freed such as journal data etc or it introduces extra > > IO. Actually, this patch is inspired by a practical problem we just > > run across which the bh remains on LRU for a long time since it is > > attached to a journal_head that can not be freed by jbd2. > > Okay, but I assume (as stated) this patch does not have an affect on > that, or am I missing something? No, this is actually a migration failure issue[1] related to cma_alloc where the bh keeps busy as the journal's transaction can't be launched[2][3][4][5][6]. I am just inspired by this issue to check if there is anything to do in reclaiming. By counting from a ramdump, there are 300MB "lru, private" pages found in a 6GB RAM system which could lower the reclaiming efficiency if the same scenario as above happens. [1] crash_arm64_v8.0.4++> kmem -p|grep ffffff808f0aa150(sb->s_bdev->bd_inode->i_mapping) fffffffe01a51c00 e9470000 ffffff808f0aa150 3 2 8000000008020 lru,private //within CMA area fffffffe03d189c0 174627000 ffffff808f0aa150 4 2 2004000000008020 lru,private fffffffe03d88e00 176238000 ffffff808f0aa150 3f9 2 2008000000008020 lru,private fffffffe03d88e40 176239000 ffffff808f0aa150 6 2 2008000000008020 lru,private fffffffe03d88e80 17623a000 ffffff808f0aa150 5 2 2008000000008020 lru,private fffffffe03d88ec0 17623b000 ffffff808f0aa150 1 2 2008000000008020 lru,private fffffffe03d88f00 17623c000 ffffff808f0aa150 0 2 2008000000008020 lru,private fffffffe040e6540 183995000 ffffff808f0aa150 3f4 2 2004000000008020 lru,private [2] page -> buffer_head crash_arm64_v8.0.4++> struct page.private fffffffe01a51c00 -x private =3D 0xffffff802fca0c00 [3] buffer_head -> journal_head crash_arm64_v8.0.4++> struct buffer_head.b_private 0xffffff802fca0c00 b_private =3D 0xffffff8041338e10, [4] journal_head -> b_cp_transaction crash_arm64_v8.0.4++> struct journal_head.b_cp_transaction 0xffffff8041338e= 10 -x b_cp_transaction =3D 0xffffff80410f1900, [5] transaction_t -> journal crash_arm64_v8.0.4++> struct transaction_t.t_journal 0xffffff80410f1900 -x t_journal =3D 0xffffff80e70f3000, [6] j_free & j_max_transaction_buffers (j_free > j_max_transaction_buffers, transaction would NOT be launched) crash_arm64_v8.0.4++> struct journal_t.j_free,j_max_transaction_buffers 0xffffff80e70f3000 -x j_free =3D 0x3f1, j_max_transaction_buffers =3D 0x100, > > I assume you have some way to test before/after, if you run into similar > problems in practice. We solve the migration issue by moving the affected file to a none-journal disk. Whereas, I think the buffered folio issue(carrying meta data) could be taken into consideration to do something. > > -- > Cheers, > > David / dhildenb >