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 6BBD9C433F5 for ; Thu, 28 Apr 2022 08:44:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3C696B0071; Thu, 28 Apr 2022 04:44:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEC9A6B0072; Thu, 28 Apr 2022 04:44:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8C806B0073; Thu, 28 Apr 2022 04:44:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id CA53C6B0071 for ; Thu, 28 Apr 2022 04:44:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id A2F45121AD9 for ; Thu, 28 Apr 2022 08:44:20 +0000 (UTC) X-FDA: 79405651080.17.BBEA91D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf19.hostedemail.com (Postfix) with ESMTP id E30921A004C for ; Thu, 28 Apr 2022 08:44:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651135459; h=from:from: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; bh=n3mG7OCWwWi6M3HbCNxE1UVDPEiuEaK15OULCVjtY8o=; b=G6MKrfhoWwTjt8AxCAYMlAHhG+KbRNIzsUL8sjKaGM5n/DItIRb74m5IRneaDMN2KioSIP /ZssTCzeaBxVAKSqhxBVDeAdVqEVaW+gV1IAYXGgJtzHZrfnRw81G1AdEFpSuxMNDsOHqB giPY0UMoxr84+05AKduEoeSg13YPCIc= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-137-UbJsIqVuPGmQQi2N3Hv3Bg-1; Thu, 28 Apr 2022 04:44:18 -0400 X-MC-Unique: UbJsIqVuPGmQQi2N3Hv3Bg-1 Received: by mail-wm1-f72.google.com with SMTP id n37-20020a05600c502500b0038fdc1394c6so1651739wmr.6 for ; Thu, 28 Apr 2022 01:44:18 -0700 (PDT) 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 :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=n3mG7OCWwWi6M3HbCNxE1UVDPEiuEaK15OULCVjtY8o=; b=Z4XeEH2vqZFKV17S9Gel/DPUhDfdPiJnPE3AYDx4C0KjF9WwCy2SW3+YDJXxvaMfiA viRfBnP7UgNtZTDH7PloAdvoLHlkqHgifNeqGVuWj/RbXIt5VVPMvqyPD4uOJooENXUF OQfcxVQg0r1WISiLwje5kNT5N3qLreVLDF4/J6LXjNqJ9nv5GoMiVVFwVSS7jAenjMiB 4I3tf72zgjSFaqc+KS/H4C/GqDLmT9alycKIFDe7FjoQd8hxlrwSpvGP1SysZY6p9Mu1 DCToc4OrevU6o2wHl1lOh9f9gno6GOO5CCwo7+PECauDZL6vQXYWzGE5p1YQJG+hK3km ssxw== X-Gm-Message-State: AOAM530ad6tNzrJ5V4x2GUx1q8dTHHjRyy1jREQCfXLxSpymHZzcxlC4 GYv8JCI8xTObr3ocmY4ZstFmabpHA9JBEU5wXPuD2VJ01cNKr3i+V/8AVghbUdVorcRPHRN/6Jv nIX5+seDGWmU= X-Received: by 2002:a1c:1947:0:b0:392:b883:aac9 with SMTP id 68-20020a1c1947000000b00392b883aac9mr29100878wmz.155.1651135457032; Thu, 28 Apr 2022 01:44:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyeSreX4jrrkiol2W8yhE4l74/X3ldbnoEnA/m0SAs98NLzNAnN4IKbE3Tf+6522jzFOLuWlA== X-Received: by 2002:a1c:1947:0:b0:392:b883:aac9 with SMTP id 68-20020a1c1947000000b00392b883aac9mr29100860wmz.155.1651135456802; Thu, 28 Apr 2022 01:44:16 -0700 (PDT) Received: from ?IPV6:2003:cb:c708:ef00:7443:a23c:26b8:b96? (p200300cbc708ef007443a23c26b80b96.dip0.t-ipconnect.de. [2003:cb:c708:ef00:7443:a23c:26b8:b96]) by smtp.gmail.com with ESMTPSA id bj3-20020a0560001e0300b0020af3d365f4sm1906215wrb.98.2022.04.28.01.44.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Apr 2022 01:44:16 -0700 (PDT) Message-ID: Date: Thu, 28 Apr 2022 10:44:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= Cc: Naoya Horiguchi , "linux-mm@kvack.org" , Andrew Morton , Miaohe Lin , Mike Kravetz , Yang Shi , Oscar Salvador , Muchun Song , "linux-kernel@vger.kernel.org" References: <20220427042841.678351-1-naoya.horiguchi@linux.dev> <54399815-10fe-9d43-7ada-7ddb55e798cb@redhat.com> <20220427122049.GA3918978@hori.linux.bs1.fc.nec.co.jp> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC PATCH v1 0/4] mm, hwpoison: improve handling workload related to hugetlb and memory_hotplug In-Reply-To: <20220427122049.GA3918978@hori.linux.bs1.fc.nec.co.jp> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E30921A004C X-Stat-Signature: uxpeqpakez7i9qam8ga6o5rox6upa6oj X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G6MKrfho; spf=none (imf19.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam09 X-HE-Tag: 1651135455-985138 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: >> 2) It happens rarely (ever?), so do we even care? > > I'm not certain of the rarity. Some cloud service providers who maintain > lots of servers may care? About replacing broken DIMMs? I'm not so sure, especially because it requires a special setup with ZONE_MOVABLE (i.e., movablecore) to be somewhat reliable and individual DIMMs can usually not get replaced at all. > >> 3) Once the memory is offline, we can re-online it and lost HWPoison. >> The memory can be happily used. >> >> 3) can happen easily if our DIMM consists of multiple memory blocks and >> offlining of some memory block fails -> we'll re-online all already >> offlined ones. We'll happily reuse previously HWPoisoned pages, which >> feels more dangerous to me then just leaving the DIMM around (and >> eventually hwpoisoning all pages on it such that it won't get used >> anymore?). > > I see. This scenario can often happen. > >> >> So maybe we should just fail offlining once we stumble over a hwpoisoned >> page? > > That could be one choice. > > Maybe another is like this: offlining can succeed but HWPoison flags are > kept over offline-reonline operations. If the system noticed that the > re-onlined blocks are backed by the original DIMMs or NUMA nodes, then the > saved HWPoison flags are still effective, so keep using them. If the > re-onlined blocks are backed by replaced DIMMs/NUMA nodes, then we can clear > all HWPoison flags associated with replaced physical address range. This > can be done automatically in re-onlining if there's a way for kernel to know > whether DIMM/NUMA nodes are replaced with new ones. But if there isn't, > system applications have to check the HW and explicitly reset the HWPoison > flags. Offline memory sections have a stale memmap, so there is no trusting on that. And trying to work around that or adjusting memory onlining code overcomplicates something we really don't care about supporting. So if we continue allowing offlining memory blocks with poisoned pages, we could simply remember that that memory block had any posioned page (either for the memory section or maybe better for the whole memory block). We can then simply reject/fail memory onlining of these memory blocks. So that leaves us with either 1) Fail offlining -> no need to care about reonlining 2) Succeed offlining but fail re-onlining -- Thanks, David / dhildenb