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 8A16AC28D13 for ; Sat, 20 Aug 2022 00:45:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08CFF8D0003; Fri, 19 Aug 2022 20:45:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03BBA8D0002; Fri, 19 Aug 2022 20:45:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E45308D0003; Fri, 19 Aug 2022 20:45:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D548C8D0002 for ; Fri, 19 Aug 2022 20:45:43 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B095612046A for ; Sat, 20 Aug 2022 00:45:43 +0000 (UTC) X-FDA: 79818128166.09.1989168 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf03.hostedemail.com (Postfix) with ESMTP id 3214820013 for ; Sat, 20 Aug 2022 00:45:43 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E9DC4B8299F; Sat, 20 Aug 2022 00:45:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56061C433D6; Sat, 20 Aug 2022 00:45:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1660956340; bh=sjupP4LfFYeTFoCxbxb9LrYe8bBDx+IgsJcmlQbxNS8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=2GN1tpo1ESbHTBvjfu5OFqoI+KtFLRHldvO1kv6/YwxgVOe2z/6U+VELNvSYt/Wtp fGJlQW1F0XIiZBXdP+rUUt8IzdcMkdoF8akh4i+xrTrt23Bq2jaOJYqWZUb3Oiis9o majJ1vQertSh7LIPdHns05H3IHfE+HcnN3ywDyt8= Date: Fri, 19 Aug 2022 17:45:39 -0700 From: Andrew Morton To: Yin Fengwei Cc: linux-mm@kvack.org, naoya.horiguchi@nec.com, linmiaohe@huawei.com, willy@infradead.org, shy828301@gmail.com, aaron.lu@intel.com, tony.luck@intel.com, qiuxu.zhuo@intel.com Subject: Re: [PATCH v3] mm: release private data before split THP Message-Id: <20220819174539.c66a67c3f2cdc5604fcbd244@linux-foundation.org> In-Reply-To: <20220810064907.582899-1-fengwei.yin@intel.com> References: <20220810064907.582899-1-fengwei.yin@intel.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=2GN1tpo1; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660956343; a=rsa-sha256; cv=none; b=eUu4utnUsFuRXRi8HT0Q0LpCaYphAE2FSBEFH8G1PA11vBQ7mea19GNgI+sWFgZFnGhpda OTeSgIWvXTJpRCY9Muo5i37DbpH0vZlBNLLEyFNpd15WsNfICIrJdYO/fQRC3mv4TBypuM b6R5JQYUfDsmEEjobuwVhVNI9q3XpGc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660956343; 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=MkBXUy2Eu8G+fOQdySHWqsNkFQpcajF37JKmButkVyk=; b=nGuQe1f1GRR6X/nYQgqCDjMT2/Z03urBSXgGu9TAepb5fwn5GkPPTQDsepPz1A0sAF+eHG WIdhPYkYNeSs58EkJgys+AOc4wevT2oLJIjK7Z62ajUZhHs5p7+vvERcUZ/It2ecAnkz0z h4CaPUaxiP58ujvcTdelemsNEYAK/xk= X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=2GN1tpo1; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam02 X-Stat-Signature: fy3o6hbgcy7arm4ytgm75pm39bu5pafa X-Rspamd-Queue-Id: 3214820013 X-HE-Tag: 1660956343-494830 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: On Wed, 10 Aug 2022 14:49:07 +0800 Yin Fengwei wrote: > If there is private data attached to THP, the refcount of > THP will be increased and block the THP split. Release > private data attached to THP before split it to increase > the chance of splitting THP successfully. > > There was a memory failure issue hit during HW error > injection testing with 5.18 kernel + xfs as rootfs. Test > got killed and system reboot was required to re-run the > test. > > The issue was tracked down to THP split failure caused the > memory failure not being handled. The page dump showed: > > [ 1785.433075] page:0000000025f9530b refcount:18 mapcount:0 mapping:000000008162eea7 index:0xa10 pfn:0x2f0200 > [ 1785.443954] head:0000000025f9530b order:4 compound_mapcount:0 compound_pincount:0 > [ 1785.452408] memcg:ff4247f2d28e9000 > [ 1785.456304] aops:xfs_address_space_operations ino:8555182 dentry name:"baseos-filenames.solvx" > [ 1785.466612] flags: 0x1000000000012036(referenced|uptodate|lru|active|private|head|node=0|zone=2) > [ 1785.476514] raw: 1000000000012036 ffb9460f8bc07c08 ffb9460f8bc08408 ff4247f22e6299f8 > [ 1785.485268] raw: 0000000000000a10 ff4247f194ade900 00000012ffffffff ff4247f2d28e9000 > > It was like the error was injected to a large folio for xfs > with private data attached. > > With private data released before split THP, the test case > could be run successfully many times without reboot system. I did a bit of editorial work on the changelog. Please check, Note my addition of "attempt to" to the second sentence. : If there is private data attached to a THP, the refcount of THP will be : increased and will prevent the THP from being split. Attempt to release : any private data attached to the THP before attempting the split to : increase the chance of splitting successfully. : : There was a memory failure issue hit during HW error injection testing : with 5.18 kernel + xfs as rootfs. The test was killed and a system reboot : was required to re-run the test. : : The issue was tracked down to a THP split failure caused by the memory : failure not being handled. The page dump showed: : : [ 1785.433075] page:0000000025f9530b refcount:18 mapcount:0 mapping:000000008162eea7 index:0xa10 pfn:0x2f0200 : [ 1785.443954] head:0000000025f9530b order:4 compound_mapcount:0 compound_pincount:0 : [ 1785.452408] memcg:ff4247f2d28e9000 : [ 1785.456304] aops:xfs_address_space_operations ino:8555182 dentry name:"baseos-filenames.solvx" : [ 1785.466612] flags: 0x1000000000012036(referenced|uptodate|lru|active|private|head|node=0|zone=2) : [ 1785.476514] raw: 1000000000012036 ffb9460f8bc07c08 ffb9460f8bc08408 ff4247f22e6299f8 : [ 1785.485268] raw: 0000000000000a10 ff4247f194ade900 00000012ffffffff ff4247f2d28e9000 : : It was like the error was injected to a large folio for xfs with private : data attached. : : With private data released before splitting the THP, the test case could : be run successfully many times without rebooting the system. > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > > ... > > @@ -2635,8 +2637,16 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > goto out; > } > > - xas_split_alloc(&xas, head, compound_order(head), > - mapping_gfp_mask(mapping) & GFP_RECLAIM_MASK); > + gfp = current_gfp_context(mapping_gfp_mask(mapping) & > + GFP_RECLAIM_MASK); > + > + if (folio_test_private(folio) && > + !filemap_release_folio(folio, gfp)) { > + ret = -EBUSY; > + goto out; > + } > + > + xas_split_alloc(&xas, head, compound_order(head), gfp); Because I assume we run into the same problem if filemap_release_folio() fails?