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 86965C7EE23 for ; Thu, 18 May 2023 16:10:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11FC6900006; Thu, 18 May 2023 12:10:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D087900004; Thu, 18 May 2023 12:10:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED9AE900006; Thu, 18 May 2023 12:10:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DBB46900004 for ; Thu, 18 May 2023 12:10:54 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9445914085C for ; Thu, 18 May 2023 16:10:54 +0000 (UTC) X-FDA: 80803864428.15.A689DAB Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf27.hostedemail.com (Postfix) with ESMTP id 03CFF40009 for ; Thu, 18 May 2023 16:10:51 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=M5x2tqEe; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684426252; 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=QJ6fEh41sGhN6IZlpmir3nTFUB9eH0sY819Rneyh7hs=; b=ht5pe7GxvQOCAQheCySvyesVVzjgUsZR4cems89cJM1HdDCX057La9YbsaSRQBM0LQxb6D W+476QtW1i06hWIEpZ/hnVQT7ZCR+QlOeUZAUyviVmfmT3xi+VgSD08BlHxpqy2stpvqJh sCA7Dz4OLGSkQTGWgXZU9LoZi/aQMN8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=M5x2tqEe; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684426252; a=rsa-sha256; cv=none; b=iUOjEMavthqWrCUJ6gf1b5aUWnR3MGr0WjDW8025mxGX+3nhuuHA/ldeQ1bV0B1XBiTENk QSn6uOPPynI9MWR3exzRfve/LpDOGrbJYEVc/mrZY5TxCe/yU/knK8UthRC25n+IMkEZmE kDbDXrPXSaG93D2MZbT8cZmrE839QQA= Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-ba7854ff5abso3182156276.2 for ; Thu, 18 May 2023 09:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684426251; x=1687018251; 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=QJ6fEh41sGhN6IZlpmir3nTFUB9eH0sY819Rneyh7hs=; b=M5x2tqEeI57jIhJIrwT/dCbMeRbiRpHmvZNAWJiNpy40KrdFIp5OS9dYYy1e+D8dOn IfwIEE0xaaAOOfDWXqcYDcFZXnf+CRUoShJLukUdSIMfeZrbDgH7G426eyZfVMceDYIK b7tsc0oHq2U1GAI6umpCTWXoyWXMAn9vk4jP1zK8OrpYNxLrEtG1uT5cwT9WuPewW6ZF DbFVz1U3IOl899F5VkE5pzMiqYp8+AhyAgt66xAScDz//OS/crWLfMBQ2MJoiQN/4Ia0 mIUHXz5mgHZvrKk+sstrxm5PC+9YnFIe8/y6//0SAK0knMZrMNjywfQBjn233QCCASuA PDdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684426251; x=1687018251; 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=QJ6fEh41sGhN6IZlpmir3nTFUB9eH0sY819Rneyh7hs=; b=dDIxpJ9D8j4fNizy8aIUPwiBHOtR80jXcqikvVIk0zRPjqCGZxP+Sh6UYMZXIhpYQV IzEzZlMqDjNGAby/rdOfE61myahAO1m8HYepoVRthDqiMfFvwPFO+f5vn0mVJm22Kobn 28e9upoTfwJ1o4jXbAC+8zvOlLvawzN5QG2oKJWEbuAfRxvlkhH75C9LOb57P9awMfRJ AGa3R3lfUOEW8748cihP24qb2+46UtIS7HUUs2+VAolmd/X6LhlysoGhbNjqkOlzKGCT MI16QxTD+QtiGDZ5YGwhO2dZ3UuJgeBJ4J5zJJrkS9g0QETYpMXMMHh8xlQHR9H1QinO NxIg== X-Gm-Message-State: AC+VfDwUbqBTqAUM+UnA72fghsukFInaGGkwQp0mzCN/579iWN9gzjvs iiIcQ3V/YCy3WaAD18yfTUBSGsC3RRm1ti6CdB2EqQ== X-Google-Smtp-Source: ACHHUZ6u/qM9qzGiehyROZJRL8PBkBdsgxRiwT6kRoso8gCcRwKce5PfQyVRrORdKNSrhUc3GOAbwMek5rHdCHurX1s= X-Received: by 2002:a25:d043:0:b0:ba8:2317:e74f with SMTP id h64-20020a25d043000000b00ba82317e74fmr2068931ybg.60.1684426250788; Thu, 18 May 2023 09:10:50 -0700 (PDT) MIME-Version: 1.0 References: <20230517160948.811355-1-jiaqiyan@google.com> <20230517233020.GA10757@monkey> In-Reply-To: <20230517233020.GA10757@monkey> From: Jiaqi Yan Date: Thu, 18 May 2023 09:10:39 -0700 Message-ID: Subject: Re: [PATCH v1 0/3] Improve hugetlbfs read on HWPOISON hugepages To: Mike Kravetz Cc: songmuchun@bytedance.com, naoya.horiguchi@nec.com, shy828301@gmail.com, linmiaohe@huawei.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, duenwen@google.com, axelrasmussen@google.com, jthoughton@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 03CFF40009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: y97dg4jrt91iaica5kwwbpo9we8a1t9h X-HE-Tag: 1684426251-218178 X-HE-Meta: U2FsdGVkX1/1J0eiPYgA0hcVCvLW6oNGcG7ylpWgpUaOReCQ97ZzPX7y2MUt1wsoJ6BAAJoOuadMXSoHalGy2yVRbhXEzO8CSVVxsABdMnjbDuCZo14amyRMHAYFLczb6U+hKy3BDsqZqYgwaK9qVaqKKSYUaNtDM6IRBOtKajTf6TRItbwe+AtSaSj4VX6rwWJ25UcyZlweIl9tTABKPLk/k5irXGnepymyNIRMog0vpQSzDt1RYfDjZbwBS7hE+Zq6TwA8O2Zj21xRs442NJF32kjfxGOj0BHrIDWhsEP03IP7nSLJOWffmp3r+cFTBbEHNPVvBo/COZBH6Vq6OfGF6OSk9v3bmTtihP3++/d6xoRrfRb4ccj4smLJVsBKN1EQz4cGic9lQF3Rcy/yW2If2RSIJpLgdpRF51xYvkn9USp6JpYzWTYKZg+FKWN+3225lkOAl6CjJStnzl27DktLJIcB97VbJvLlLJ4vm0gQUE0VfF84Q3bq/VgXUgORouM+TwXDpW58IC3lnEw8MGcRg4cFGhb+79E52z+k71oSWQamSEfn+0x8PEOihPW0voMIWFTTx69SYe9kVcYhKzws9HAVKwK5wTJNqUfdF8PdPcCsaoWpdHWASYBnQDr3lJZY+mc89rfWV544DuJbopa4tGN2eiRVa9Al/NC6Fihl2qoQVFit7V188SJhlqcRHsgypX1KsWw8Y9H7AlE9Hr1TyCNapbTNXZg3dtWgQskhDvb5ANuuuP//WuPrFUiB0PhCQ1hNOtCMibfYwy+O0DoriJToFss8cesmMqEsEn2x4ytIWggmDaaYw8oiXlkvbLwBHVeqVtd4QAgHyuO7smuc1pdna7Kl379TQsPrJqNO9FzhlNusJ6tiPgrQsmuCd+f8EYr6dX7PA2JMupj8liqjLSOm9l+2zDZyuHSrBMPN3C4nVHR/ZcUcIn5nvFRO5G8nu0B721xWjynUcCE I+UD4UD/ oIwmgyJoZdZDhv8niuvscQDiSw0qI16YH2i0J/3gCGEogon0Tpsd0fQA4cLT3yr7LKiewjllLM/4WFVNzBHof+SiDCzpySLWMSEvDx2K0ZGYHEtxLhDuqMKN65M9WxZmx6ilshj3tHYj/gcX0XeKaJnzn7jlOn74g0T9xPXi1lS3On7zlSdkWzCAlbdzVzjwdID27jG2QZgxYN3jc+wFtaLV/TZl5sYNGHqgugVdXxBLdq8xb2u3wwDCJddYvZqwp8sBtfgp4uNThZL8rGHNv0eEvHnexD1theRZPZM5Tpk/9fOxDaLD8hRdYWKr8fjqhP3NHpC6llgmO9Hs= 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, May 17, 2023 at 4:30=E2=80=AFPM Mike Kravetz wrote: > > On 05/17/23 16:09, Jiaqi Yan wrote: > > Today when hardware memory is corrupted in a hugetlb hugepage, > > kernel leaves the hugepage in pagecache [1]; otherwise future mmap or > > read will suject to silent data corruption. This is implemented by > > returning -EIO from hugetlb_read_iter immediately if the hugepage has > > HWPOISON flag set. > > > > Since memory_failure already tracks the raw HWPOISON subpages in a > > hugepage, a natural improvement is possible: if userspace only asks for > > healthy subpages in the pagecache, kernel can return these data. > > Thanks for putting this together. > > I recall discussing this some time back, and deciding to wait and see > how HGM would progress. Since it may be some time before HGM goes > upstream, it would be reasonable to consider this again. This improvement actually does NOT depend on HGM at all. No page table related stuff involved here. The other RFC [2] I sent earlier DOES require HGM. This improvement was brought up by James when we were working on [2]. In "Future Work" section of the cover letter, I thought HGM was needed but soon when I code it up, I found I was wrong. > > One quick question. > Do you have an actual use case for this? It certainly is an improvement > over existing functionality. However, I am not aware of too many (?any?) > users actually doing read() calls on hugetlb files. I don't have any use case. I did search on Github for around half a hour and all the hugetlb usages are done via mmap. > -- > Mike Kravetz > > > This patchset implements this improvement. It consist of three parts. > > The 1st commit exports the functionality to tell if a subpage inside a > > hugetlb hugepage is a raw HWPOISON page. The 2nd commit teaches > > hugetlbfs_read_iter to return as many healthy bytes as possible. > > The 3rd commit properly tests this new feature. > > > > [1] commit 8625147cafaa ("hugetlbfs: don't delete error page from pagec= ache") [2] https://lore.kernel.org/linux-mm/20230428004139.2899856-6-jiaqiyan@goog= le.com/T/#m97c6edef8ad0cc9b064e1fd9369b8521dcfa43de > > > > Jiaqi Yan (3): > > mm/hwpoison: find subpage in hugetlb HWPOISON list > > hugetlbfs: improve read HWPOISON hugepage > > selftests/mm: add tests for HWPOISON hugetlbfs read > > > > fs/hugetlbfs/inode.c | 62 +++- > > include/linux/mm.h | 23 ++ > > mm/memory-failure.c | 26 +- > > tools/testing/selftests/mm/.gitignore | 1 + > > tools/testing/selftests/mm/Makefile | 1 + > > .../selftests/mm/hugetlb-read-hwpoison.c | 322 ++++++++++++++++++ > > 6 files changed, 419 insertions(+), 16 deletions(-) > > create mode 100644 tools/testing/selftests/mm/hugetlb-read-hwpoison.c > > > > -- > > 2.40.1.606.ga4b1b128d6-goog > > (Sorry if you received twice, was sent in a wrong way a while ago)