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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B7B8C433DF for ; Tue, 23 Jun 2020 21:48:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D1B812078A for ; Tue, 23 Jun 2020 21:48:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="F1lsia2r" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1B812078A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1B58E6B0002; Tue, 23 Jun 2020 17:48:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13E306B0003; Tue, 23 Jun 2020 17:48:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F20D36B0005; Tue, 23 Jun 2020 17:48:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id D42486B0002 for ; Tue, 23 Jun 2020 17:48:26 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 45B9E180AD837 for ; Tue, 23 Jun 2020 21:48:26 +0000 (UTC) X-FDA: 76961815812.08.store36_2512aac26e3e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 13ED81819DF1B for ; Tue, 23 Jun 2020 21:48:26 +0000 (UTC) X-HE-Tag: store36_2512aac26e3e X-Filterd-Recvd-Size: 4544 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 23 Jun 2020 21:48:24 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id dg28so1880411edb.3 for ; Tue, 23 Jun 2020 14:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XKFP4XmM+fzPiSTcosfxpar/wTtCL35clRf++Z9m9ME=; b=F1lsia2rHf1QjZHwmwFyb3rl/n1GTyxCp+pL4CQHVcYaIpRBQYuLp4VEvV3gTVzC6T Y0ZYtALWifMR47OpgIRXM+ZsNLyRakdttcIh1QXcyW2CAiGQCsWbnM2I+gyyYl6mOZI/ JhkUDtfG2igjjw82AeihWkKCAY8uQjW8NlLFku1IHUco3VDRgf26H5wOdykBehKwbKD7 zXhSocoxUkZekHACS2I7zQH1A44s44Foxo8kZI1Gfhg1+uuLgPmOLjIew4Ex/0pwVJpV iKTFVQcUjN50tdl3MkEkyPSFTjCpyPvys3RVxOb0l88vM9dYQ/ZIXUKrz2dOPmEtnOWg aZyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XKFP4XmM+fzPiSTcosfxpar/wTtCL35clRf++Z9m9ME=; b=syoFiPKdKPn4B2gvvak56DY9uM2D7t1bunx8XVbTIDQok8nULrpcXWw9kokyM8hZUy trCmIMgKswUD/UMFxP3Drvlj0NBR5qFs5YpArHGZkZSnqWJSnIyUz3Csp/kgjPruaVsm 3OmLyXKdEnQNmmFkZlnz5K6MgMM/bbXGMPW4RFKJ6uF++eayQSIusw28nrCWznSXauIq a5RC5nQRVDJ4b+n8PgNDRZdu2EX6q+zsnmkrSKeoZExePkVjbQFmxOxD9YzQZDaZomq9 lzpDsNKCOWP0fd2NtEHv/RHfqv0ALdTtouSz8QBRLZmPRj/dxgSzbSzpm8AajRONsgND 9a5w== X-Gm-Message-State: AOAM530PB4Zq5I5lEg2KzXG84KRGkHPOc9MhdOyPc4ooGiZpthcb5vwc PBuNIv0mq9e7olLh5jCfUDWmZjDzixeZJZ3DzVhApw== X-Google-Smtp-Source: ABdhPJzeX9nxsXA3Zu7wxZMKFugqzwy3MnzLxu2GT5SKfmIE4H+3rsuLUjVpi+jCAWejZXkG9uDyiRHh1AF4zIqmMME= X-Received: by 2002:a50:a1e7:: with SMTP id 94mr23236130edk.165.1592948903362; Tue, 23 Jun 2020 14:48:23 -0700 (PDT) MIME-Version: 1.0 References: <20200623201745.GG21350@casper.infradead.org> In-Reply-To: <20200623201745.GG21350@casper.infradead.org> From: Dan Williams Date: Tue, 23 Jun 2020 14:48:12 -0700 Message-ID: Subject: Re: [RFC] Make the memory failure blast radius more precise To: Matthew Wilcox Cc: Tony Luck , Borislav Petkov , Naoya Horiguchi , linux-edac@vger.kernel.org, Linux MM , linux-nvdimm , "Darrick J. Wong" , Jane Chu , david Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 13ED81819DF1B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000145, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 23, 2020 at 1:18 PM Matthew Wilcox wrote: > > > Hardware actually tells us the blast radius of the error, but we ignore > it and take out the entire page. We've had a customer request to know > exactly how much of the page is damaged so they can avoid reconstructing > an entire 2MB page if only a single cacheline is damaged. > > This is only a strawman that I did in an hour or two; I'd appreciate > architectural-level feedback. Should I just convert memory_failure() to > always take an address & granularity? Should I create a struct to pass > around (page, phys, granularity) instead of reconstructing the missing > pieces in half a dozen functions? Is this functionality welcome at all, > or is the risk of upsetting applications which expect at least a page > of granularity too high? > > I can see places where I've specified a plain PAGE_SHIFT insted of > interrogating a compound page for its size. I'd probably split this > patch up into two or three pieces for applying. > > I've also blindly taken out the call to unmap_mapping_range(). Again, > the customer requested that we not do this. That deserves to be in its > own patch and properly justified. I had been thinking that we could not do much with the legacy memory-failure reporting model and that applications that want a new model would need to opt-into it. This topic also dovetails with what Dave and I had been discussing in terms coordinating memory error handling with the filesystem which may have more information about multiple mappings of a DAX page (reflink) [1]. [1]: http://lore.kernel.org/r/20200311063942.GE10776@dread.disaster.area