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 22BB0C19F29 for ; Thu, 4 Aug 2022 02:05:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 844AE8E0005; Wed, 3 Aug 2022 22:05:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F2398E0001; Wed, 3 Aug 2022 22:05:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B9FB8E0005; Wed, 3 Aug 2022 22:05:40 -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 5CE218E0001 for ; Wed, 3 Aug 2022 22:05:40 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AD7F5816CD for ; Thu, 4 Aug 2022 02:05:37 +0000 (UTC) X-FDA: 79760268714.14.D2D98FC Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf05.hostedemail.com (Postfix) with ESMTP id 3CC90100003 for ; Thu, 4 Aug 2022 02:05:36 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4LysRj2fVSzjXg1; Thu, 4 Aug 2022 10:02:09 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 4 Aug 2022 10:05:10 +0800 Subject: Re: [RFC PATCH] mm/memory-failure: release private data before split THP To: Yin Fengwei CC: , , , , , Matthew Wilcox References: <20220803025243.155798-1-fengwei.yin@intel.com> <410bb7b3-db57-47a9-f97c-1e3441aadb23@huawei.com> <39c1f73d-d90c-1423-7bc8-a39414f2a69e@intel.com> From: Miaohe Lin Message-ID: Date: Thu, 4 Aug 2022 10:05:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <39c1f73d-d90c-1423-7bc8-a39414f2a69e@intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659578737; a=rsa-sha256; cv=none; b=kCQffcMs3mzrY3DsflGGmo849tslDoeXU+pCHDyY+v5KgclSIZzEuzUtnVXORhlv8pQO2C Xh8z/QBIoh2f1esTIZMntOlEsCUzx7PlDkvDW9vl71pXp/w/Lapghpo0QPeXv1mw/qrwU/ UwKjH+KYSU2AoH3qufOtly1DI8AmHhI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659578737; 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; bh=9mnNUrN6YO1ZQgwDM5Ne2XJiRyduKJZpqf6bokXG8QY=; b=O6/zFTFEQ59bOcI0cWXva/RAXxXJwESnt+FFxJgNzbA3o2xG7XpD/Lj2ENoWihkra3V2pL L5WJZpEK+Sv0hJYSqyyuvm3OUj0CYBJMN2xUpJNGkyI4vtL1cKlWb0nuQNtW0DY1jkWbvb lRJbO6DHjDmx0RYgWFG+1VBufgC5T9o= X-Rspamd-Server: rspam04 X-Stat-Signature: wnw5sqx4nbzj7t58gi69czw4uqu3gq6u Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspamd-Queue-Id: 3CC90100003 X-Rspam-User: X-HE-Tag: 1659578736-659687 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 2022/8/4 9:54, Yin Fengwei wrote: > On 2022/8/4 09:19, Miaohe Lin wrote: >> On 2022/8/3 21:01, Matthew Wilcox wrote: >>> On Wed, Aug 03, 2022 at 10:52:43AM +0800, Yin Fengwei wrote: >>>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >>>> index da39ec8afca8..08e21973b120 100644 >>>> --- a/mm/memory-failure.c >>>> +++ b/mm/memory-failure.c >>>> @@ -1484,7 +1484,16 @@ static int identify_page_state(unsigned long pfn, struct page *p, >>>> >>>> static int try_to_split_thp_page(struct page *page, const char *msg) >>>> { >>>> + struct page *head = compound_head(page); >>> > + >>>> lock_page(page); >>>> + /* >>>> + * If thp page has private data attached, thp split will fail. >>>> + * Release private data before split thp. >>>> + */ >>>> + if (page_has_private(head)) >>>> + try_to_release_page(head, GFP_KERNEL); >>>> + >>>> if (unlikely(split_huge_page(page))) { >>>> unsigned long pfn = page_to_pfn(page); >>> >>> It seems a shame to use the old page approach instead of the >>> shiny new folio approach. We're quite close to being able to remove >>> try_to_release_page() in 6.1 or 6.2 so adding a new caller is a bad idea. >>> How about this: >>> >>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >>> index da39ec8afca8..765b383288b1 100644 >>> --- a/mm/memory-failure.c >>> +++ b/mm/memory-failure.c >>> @@ -1484,16 +1484,21 @@ static int identify_page_state(unsigned long pfn, struct page *p, >>> >>> static int try_to_split_thp_page(struct page *page, const char *msg) >>> { >>> - lock_page(page); >>> + struct folio *folio = page_folio(page); >>> + >>> + folio_lock(folio); >>> + if (folio_test_private(folio)) >>> + filemap_release_folio(folio, GFP_KERNEL); >> >> If filemap_release_folio fails, we could avoid trying split_huge_page here? > Maybe we could stick to this regarding this is error recovery path > instead of hot path? That should be fine. Thanks.