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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 35F04CA9EA0 for ; Tue, 22 Oct 2019 09:23:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 03B7D2064B for ; Tue, 22 Oct 2019 09:23:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03B7D2064B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A22F96B0003; Tue, 22 Oct 2019 05:22:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D4196B0006; Tue, 22 Oct 2019 05:22:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E9206B0007; Tue, 22 Oct 2019 05:22:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0129.hostedemail.com [216.40.44.129]) by kanga.kvack.org (Postfix) with ESMTP id 689196B0003 for ; Tue, 22 Oct 2019 05:22:59 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id DB144181AEF32 for ; Tue, 22 Oct 2019 09:22:58 +0000 (UTC) X-FDA: 76070881236.10.toys28_19fa223c4c54d X-HE-Tag: toys28_19fa223c4c54d X-Filterd-Recvd-Size: 2984 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Oct 2019 09:22:58 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4F914AC16; Tue, 22 Oct 2019 09:22:57 +0000 (UTC) Date: Tue, 22 Oct 2019 11:22:56 +0200 From: Michal Hocko To: Oscar Salvador Cc: n-horiguchi@ah.jp.nec.com, mike.kravetz@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 10/16] mm,hwpoison: Rework soft offline for free pages Message-ID: <20191022092256.GH9379@dhcp22.suse.cz> References: <20191017142123.24245-1-osalvador@suse.de> <20191017142123.24245-11-osalvador@suse.de> <20191018120615.GM5017@dhcp22.suse.cz> <20191021125842.GA11330@linux> <20191021154158.GV9379@dhcp22.suse.cz> <20191022074615.GA19060@linux> <20191022082611.GD9379@dhcp22.suse.cz> <20191022083505.GA19708@linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191022083505.GA19708@linux> User-Agent: Mutt/1.10.1 (2018-07-13) 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 22-10-19 10:35:17, Oscar Salvador wrote: > On Tue, Oct 22, 2019 at 10:26:11AM +0200, Michal Hocko wrote: > > On Tue 22-10-19 09:46:20, Oscar Salvador wrote: > > [...] > > > So, opposite to hard-offline, in soft-offline we do not fiddle with pages > > > unless we are sure the page is not reachable anymore by any means. > > > > I have to say I do not follow. Is there any _real_ reason for > > soft-offline to behave differenttly from MCE (hard-offline)? > > Yes. > Do not take it as 100% true as I read that in some code/Documentation > a while ago. > > But I think that it boils down to: > > soft-offline: "We have seen some erros in the underlying page, but > it is still usable, so we have a chance to keep the > the contents (via migration)" > hard-offline: "The underlying page is dead, we cannot trust it, so > we shut it down, killing whoever is holding it > along the way". Hmm, that might be a misunderstanding on my end. I thought that it is the MCE handler to say whether the failure is recoverable or not. If yes then we can touch the content of the memory (that would imply the migration). Other than that both paths should be essentially the same, no? Well unrecoverable case would be essentially force migration failure path. MADV_HWPOISON is explicitly documented to test MCE handling IIUC: : This feature is intended for testing of memory error-handling : code; it is available only if the kernel was configured with : CONFIG_MEMORY_FAILURE. There is no explicit note about the type of the error that is injected but I think it is reasonably safe to assume this is a recoverable one. -- Michal Hocko SUSE Labs