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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 39BA0C433E0 for ; Tue, 23 Jun 2020 22:40:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E83022078A for ; Tue, 23 Jun 2020 22:40:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="KZfiNnU8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E83022078A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6D13C6B0002; Tue, 23 Jun 2020 18:40:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6812E6B0003; Tue, 23 Jun 2020 18:40:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 596556B0005; Tue, 23 Jun 2020 18:40:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id 3FB656B0002 for ; Tue, 23 Jun 2020 18:40:51 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C7D1F180AD83B for ; Tue, 23 Jun 2020 22:40:50 +0000 (UTC) X-FDA: 76961947860.02.door93_010a60f26e3f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 81AD130000B0D155 for ; Tue, 23 Jun 2020 22:40:50 +0000 (UTC) X-HE-Tag: door93_010a60f26e3f X-Filterd-Recvd-Size: 3401 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Tue, 23 Jun 2020 22:40:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=inf6ESzzuqFyz/AxMuegiW33kVntEASRl+Rj/szf9mM=; b=KZfiNnU89q2RuwBIHdmTN3d7Vu 3Odlb+G0HmmRGQr/HlFfPmKh7bmntcZ8rxXL28eD9QfUiiXj2zxzdKhk4nn/ORxDzA8TSIZtX2wn8 CTmbxadffG1MeJEbmsAUd99ROjuIh0IzSiuICh+TNaX7kPqBgUIojIDJQdSVM3QJugSWoyagWHSCW YY6jS8tiZltLBsjSf6ZxkwejKZkuz7+0oc4v2gQAh87fySkxJZ7yuWz7gVARXo/lK9QH9oZx0tZXY 1+iyla0naGvnDN8971quQ0klpacW64Mb30+y4OQ8bb8NOrrdPU/uAWdIdsi2X3HiUw+FTzHerjz3B 9b03vJ9g==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnrad-00013W-Gl; Tue, 23 Jun 2020 22:40:27 +0000 Date: Tue, 23 Jun 2020 23:40:27 +0100 From: Matthew Wilcox To: "Luck, Tony" Cc: Borislav Petkov , Naoya Horiguchi , linux-edac@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, "Darrick J. Wong" , Jane Chu Subject: Re: [RFC] Make the memory failure blast radius more precise Message-ID: <20200623224027.GI21350@casper.infradead.org> References: <20200623201745.GG21350@casper.infradead.org> <20200623220412.GA21232@agluck-desk2.amr.corp.intel.com> <20200623221741.GH21350@casper.infradead.org> <20200623222658.GA21817@agluck-desk2.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200623222658.GA21817@agluck-desk2.amr.corp.intel.com> X-Rspamd-Queue-Id: 81AD130000B0D155 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Tue, Jun 23, 2020 at 03:26:58PM -0700, Luck, Tony wrote: > On Tue, Jun 23, 2020 at 11:17:41PM +0100, Matthew Wilcox wrote: > > It might also be nice to have an madvise() MADV_ZERO option so the > > application doesn't have to look up the fd associated with that memory > > range, but we haven't floated that idea with the customer yet; I just > > thought of it now. > > So the conversation between OS and kernel goes like this? > > 1) machine check > 2) Kernel unmaps the 4K page surroundinng the poison and sends > SIGBUS to the application to say that one cache line is gone > 3) App says madvise(MADV_ZERO, that cache line) > 4) Kernel says ... "oh, you know how to deal with this" and allocates > a new page, copying the 63 good cache lines from the old page and > zeroing the missing one. New page is mapped to user. That could be one way of implementing it. My understanding is that pmem devices will reallocate bad cachelines on writes, so a better implementation would be: 1) Kernel receives machine check 2) Kernel sends SIGBUS to the application 3) App send madvise(MADV_ZERO, addr, 1 << granularity) 4) Kernel does special writes to ensure the cacheline is zeroed 5) App does whatever it needs to recover (reconstructs the data or marks it as gone) > Do you have folks lined up to use that? I don't know that many > folks are even catching the SIGBUS :-( Had a 75 minute meeting with some people who want to use pmem this afternoon ...