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 6EEB2C433EF for ; Fri, 6 May 2022 13:42:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB2176B0073; Fri, 6 May 2022 09:42:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D60756B0074; Fri, 6 May 2022 09:42:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDDB66B0075; Fri, 6 May 2022 09:42:27 -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 B088A6B0073 for ; Fri, 6 May 2022 09:42:27 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 881BB611FD for ; Fri, 6 May 2022 13:42:27 +0000 (UTC) X-FDA: 79435432734.19.4AF28F5 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf15.hostedemail.com (Postfix) with ESMTP id 6FE04A004E for ; Fri, 6 May 2022 13:42:16 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id l11so590206pgt.13 for ; Fri, 06 May 2022 06:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=PfUI54DC+Rd4JhaHhM79SH7hCQA6BnGmIDFJn3u5zLM=; b=aKsXfyC6aHrcUWOwO7G7UYAV68+b8gHqoJddnLu0t/IA7s7HawCsFCGO/Kujg873Y6 KVD3LFFVeuekk+wEAOPy1Y6U1hO5gUa0jLOw8Bvc5N02CNRvkanaEg2w/JG5wka+Oslx ydesijDYApsY+LM85LShGfEnGycGRv/VEdWYUy9FfhhdzljJFiBXPOyi/Pa35WArWkKX BhCl/GlGG23ObBA0eoXzfYFXawe6ko9nCA940pYhFh0G0ZTDtWM5vfpTM+6JW1Njun30 ZsFjAFyFgMjFBHj+GWTjf33CG4KH/W+9w3UtvRGjoUgC8vdqfTBth8M1FRYVYh8Z+xd5 8xFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=PfUI54DC+Rd4JhaHhM79SH7hCQA6BnGmIDFJn3u5zLM=; b=AUnhD1zueYQlQfPb0C+q9TdeOs4FkhPDeJJo+0RxfEUBOgXpsOoiFdO0dj+4E4xxI3 mPHVaLIlcRmahB4mFi2mroICw9dEjUHtmS3PDtiYrBAdOyx5XXJ93yufhXqrTQrx6oH4 Q9XTfvibWZrtiP0DDkW8k4wdNI469bhfPKQC+aK0UJI9bUGeHovwDdCGws4BBZjDqFso EYaA2NuMQJvNDx/zUWXd/BqiHYjWSuFUSZcdDLXfPVKv2urG5z80bjzFp+daVO5YvewX 8qnRxrdRtj4YDT9fHPYL1nKHpAh6zfkhjg89NdseAu7JdF9CucEd5t9shi6it4PBhtsk 0fzA== X-Gm-Message-State: AOAM531aSZrn0/yeMnNFPXSCFpRY0SJf4ANYnlr+6Tq/WpLvbHoqL5Et bT9e1/tBql0HNtW3pB85Agdkpg== X-Google-Smtp-Source: ABdhPJySJILodY6XqJPjPbH87bJIVRNRr+CgOPpU7dPLFadY++HIHQRCjgCYnQukNaA1I2A/cUztMg== X-Received: by 2002:a63:8449:0:b0:3c6:4145:6a1c with SMTP id k70-20020a638449000000b003c641456a1cmr2839205pgd.590.1651844544773; Fri, 06 May 2022 06:42:24 -0700 (PDT) Received: from [10.255.89.252] ([139.177.225.255]) by smtp.gmail.com with ESMTPSA id s14-20020a056a001c4e00b0050dc76281fesm3333258pfw.216.2022.05.06.06.42.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 06:42:24 -0700 (PDT) Message-ID: <3c0e25fb-695d-4a29-6de4-c892f89cea7a@bytedance.com> Date: Fri, 6 May 2022 21:38:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Re: [PATCH 3/4] mm/memofy-failure.c: optimize hwpoison_filter Content-Language: en-US To: Naoya Horiguchi Cc: akpm@linux-foundation.org, naoya.horiguchi@nec.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Wu Fengguang , "Michael S. Tsirkin" , David Hildenbrand , Jason Wang , "virtualization@lists.linux-foundation.org" References: <20220429142206.294714-1-pizhenwei@bytedance.com> <20220429142206.294714-4-pizhenwei@bytedance.com> <20220506085920.GC1356094@u2004> From: zhenwei pi In-Reply-To: <20220506085920.GC1356094@u2004> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: du6w39e3w7o7iig5h9x5ju79j1n3aap5 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6FE04A004E Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=aKsXfyC6; spf=pass (imf15.hostedemail.com: domain of pizhenwei@bytedance.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=pizhenwei@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspam-User: X-HE-Tag: 1651844536-88974 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 5/6/22 16:59, Naoya Horiguchi wrote: > On Fri, Apr 29, 2022 at 10:22:05PM +0800, zhenwei pi wrote: >> In the memory failure procedure, hwpoison_filter has higher priority, >> if memory_filter() filters the error event, there is no need to do >> the further work. > > Could you clarify what problem you are trying to solve (what does > "optimize" mean in this context or what is the benefit)? > OK. The background of this work: As well known, the memory failure mechanism handles memory corrupted event, and try to send SIGBUS to the user process which uses this corrupted page. For the virtualization case, QEMU catches SIGBUS and tries to inject MCE into the guest, and the guest handles memory failure again. Thus the guest gets the minimal effect from hardware memory corruption. The further step I'm working on: 1, try to modify code to decrease poisoned pages in a single place (mm/memofy-failure.c: simplify num_poisoned_pages_dec in this series). 2, try to use page_handle_poison() to handle SetPageHWPoison() and num_poisoned_pages_inc() together. It would be best to call num_poisoned_pages_inc() in a single place too. I'm not sure if this is possible or not, please correct me if I misunderstand. 3, introduce memory failure notifier list in memory-failure.c: notify the corrupted PFN to someone who registers this list. If I can complete [1] and [2] part, [3] will be quite easy(just call notifier list after increasing poisoned page). 4, introduce memory recover VQ for memory balloon device, and registers memory failure notifier list. During the guest kernel handles memory failure, balloon device gets notified by memory failure notifier list, and tells the host to recover the corrupted PFN(GPA) by the new VQ. 5, host side remaps the corrupted page(HVA), and tells the guest side to unpoison the PFN(GPA). Then the guest fixes the corrupted page(GPA) dynamically. Because [4] and [5] are related to balloon device, also CC Michael, David and Jason. > Now hwpoison_filter() can be called both with *and* without taking page refcount. > It's mainly called *with* taking page refcount in order to make sure that the > actual handling process is executed only for pages that meet a given condition. > IOW, it's important to prevent pages which do not meet the condition from going > ahead to further steps (false-positive is not permitted). So this type of > callsite should not be omittable. > > As for the other case, hwpoison_filter() is also called in hwpoison_inject() > *without* taking page refcount. This actually has a different nuance and > intended to speculatively filter the injection events before setting > PageHWPoison flag to reduce the noise due to setting PG_hwpoison temporary. > The point is that it's not intended here to filter precisely and this callsite > is omittable. > > So in my understanding, we need keep hwpoison_filter() after taking page > refcount as we do now. Maybe optionally and additionally calling > hwpoison_filter() at the beginning of memory_failure() might be possible, > but I'm not sure yet how helpful... > > Thanks, > Naoya Horiguchi > >> >> Cc: Wu Fengguang >> Signed-off-by: zhenwei pi >> --- >> mm/memory-failure.c | 14 +++++--------- >> 1 file changed, 5 insertions(+), 9 deletions(-) >> >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >> index ece05858568f..a6a27c8b800f 100644 >> --- a/mm/memory-failure.c >> +++ b/mm/memory-failure.c >> @@ -1800,6 +1800,11 @@ int memory_failure(unsigned long pfn, int flags) >> goto unlock_mutex; >> } >> >> + if (hwpoison_filter(p)) { >> + res = -EOPNOTSUPP; >> + goto unlock_mutex; >> + } >> + >> try_again: >> res = try_memory_failure_hugetlb(pfn, flags, &hugetlb); >> if (hugetlb) >> @@ -1937,15 +1942,6 @@ int memory_failure(unsigned long pfn, int flags) >> */ >> page_flags = p->flags; >> >> - if (hwpoison_filter(p)) { >> - if (TestClearPageHWPoison(p)) >> - num_poisoned_pages_dec(); >> - unlock_page(p); >> - put_page(p); >> - res = -EOPNOTSUPP; >> - goto unlock_mutex; >> - } >> - >> /* >> * __munlock_pagevec may clear a writeback page's LRU flag without >> * page_lock. We need wait writeback completion for this page or it >> -- >> 2.20.1 >> -- zhenwei pi