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 61355C433EF for ; Fri, 14 Jan 2022 13:22:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CFF56B0072; Fri, 14 Jan 2022 08:22:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 77F716B0073; Fri, 14 Jan 2022 08:22:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 621356B0074; Fri, 14 Jan 2022 08:22:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 502DE6B0072 for ; Fri, 14 Jan 2022 08:22:40 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EFD1818259E2B for ; Fri, 14 Jan 2022 13:22:39 +0000 (UTC) X-FDA: 79028957238.20.2EA7FEF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 4347640003 for ; Fri, 14 Jan 2022 13:22:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642166558; 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=oeaq06iGyvE0QAALNnhiWPGnYSnujvBuiZVqBWtdPcQ=; b=GLM4PNOLO76exaLiapDScAvMqMI8v4Osy92YUsa2i7LSptqZfpylpWur4kO8t1IsSxRE2e Qe7PxETOfO7m2AxqnSgGtTS10kqhPFEIR6TZ4puVvTuNx+lxJtIrNdPrfV4kguF53CvQNn mtD5gZW52syBY0nJ+ZTU0naa4//gOeE= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-369-5OlvDEqhNEOz-qqUIRJzjQ-1; Fri, 14 Jan 2022 08:22:37 -0500 X-MC-Unique: 5OlvDEqhNEOz-qqUIRJzjQ-1 Received: by mail-ed1-f70.google.com with SMTP id c8-20020a05640227c800b003fdc1684cdeso8367806ede.12 for ; Fri, 14 Jan 2022 05:22:37 -0800 (PST) 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=oeaq06iGyvE0QAALNnhiWPGnYSnujvBuiZVqBWtdPcQ=; b=VBlhWr5DfWD9XBoeFgxxvVSwB3N9pv73JTkZt71GM2rs69sIyMLMwg8IWrJzjqRduS 1Jqr+ExmI/XS6PTs2eHQaq2rOc+LMp2fQaBSb8hSl6K0bMaQIfR0k/IIe4tlV6zMWcU4 80ig18IXBP3lpFcHEL05GPB5tIxTBvGlz9xZaH40AN8LEjW9GOwZupbqThb3WVlWftNM OvyK+lsa8wbrBSyisJP/vrwXUbz3+fkbXcObLKUTf4AxRkAKMOeoyL8WuCH7mytE5OYk PxeaSRsfjB97/T+JCZze/laByqWQ4m75x8fJLKbb+iGvHl8A8Hm3mm042YNPmR0Lm0WI 02fA== X-Gm-Message-State: AOAM530u0SGMIPJWg2tk+/Tql0cV31Xyazl22NQK8E0NQy7ZlcORQT0T C/LQE1ZSqMlYkvnVcs/8Z1f8u6VxktVH1FrZSFAaIMIvy3nvvY/Fmm8WP/fBGPzV4NqXubmP3Cf RmFJxbf2ZHKI= X-Received: by 2002:a17:907:da0:: with SMTP id go32mr7626101ejc.206.1642166556211; Fri, 14 Jan 2022 05:22:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJxS9vZNX3oQ6i39jM2FKgLuz6f8PXERubRE87h6Ubd8Gv/YN4aNXBeXwCcra2gmHtmx8Cv73A== X-Received: by 2002:a17:907:da0:: with SMTP id go32mr7626059ejc.206.1642166555864; Fri, 14 Jan 2022 05:22:35 -0800 (PST) Received: from ?IPV6:2003:cb:c701:9d00:ff87:1c9b:108a:9702? (p200300cbc7019d00ff871c9b108a9702.dip0.t-ipconnect.de. [2003:cb:c701:9d00:ff87:1c9b:108a:9702]) by smtp.gmail.com with ESMTPSA id o1sm2377554edv.2.2022.01.14.05.22.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 05:22:35 -0800 (PST) Message-ID: <1549f9f8-92a5-21f6-23ef-f3e6217df1c3@redhat.com> Date: Fri, 14 Jan 2022 14:22:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: "Kirill A. Shutemov" Cc: Dave Hansen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220111113314.27173-1-kirill.shutemov@linux.intel.com> <20220111113314.27173-2-kirill.shutemov@linux.intel.com> <3a68fabd-eaff-2164-5609-3a71fd4a7257@intel.com> <20220112191510.6uqdflbreuet7bnx@box.shutemov.name> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCHv2 1/7] mm: Add support for unaccepted memory In-Reply-To: <20220112191510.6uqdflbreuet7bnx@box.shutemov.name> 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-Server: rspam11 X-Rspamd-Queue-Id: 4347640003 X-Stat-Signature: dg1a6ebqbga3sxf8h3r3jyaxm8ubkwsp Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GLM4PNOL; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf27.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1642166559-608474 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 12.01.22 20:15, Kirill A. Shutemov wrote: > On Wed, Jan 12, 2022 at 12:31:10PM +0100, David Hildenbrand wrote: >> >>> >>> Looking at stuff like this, I can't help but think that a: >>> >>> #define PageOffline PageUnaccepted >>> >>> and some other renaming would be a fine idea. I get that the Offline >>> bit can be reused, but I'm not sure that the "Offline" *naming* should >>> be reused. What you're doing here is logically distinct from existing >>> offlining. >> >> Yes, or using a new pagetype bit to make the distinction clearer. >> Especially the function names like maybe_set_page_offline() et. Al are >> confusing IMHO. They are all about accepting unaccepted memory ... and >> should express that. > > "Unaccepted" is UEFI treminology and I'm not sure we want to expose > core-mm to it. Power/S390/ARM may have a different name for the same > concept. Offline/online is neutral terminology, familiar to MM developers. Personally, I'd much rather prefer clear UEFI terminology for now than making the code more confusing to get. We can always generalize later iff there are similar needs by other archs (and if they are able to come up witha better name). But maybe we can find a different name immediately. The issue with online vs. offline I have is that we already have enough confusion: offline page: memory section is offline. These pages are not managed by the buddy. The memmap is stale unless we're dealing with special ZONE_DEVICE memory. logically offline pages: memory section is online and pages are PageOffline(). These pages were removed from the buddy e.g., to free them up in the hypervisor. soft offline pages: memory section is online and pages are PageHWPoison(). These pages are removed from the buddy such that we cannot allocate them to not trigger MCEs. offline pages are exposed to the buddy by onlining them (generic_online_page()), which is init+freeing. PageOffline() and PageHWPoison() are onlined by removing the flag and freeing them to the buddy. Your case is different such that the pages are managed by the buddy and they don't really have online/offline semantics compared to what we already have. All the buddy has to do is prepare them for initial use. I'm fine with reusing PageOffline(), but for the purpose of reading the code, I think we really want some different terminology in page_alloc.c So using any such terminology would make it clearer to me: * PageBuddyUnprepared() * PageBuddyUninitialized() * PageBuddyUnprocessed() * PageBuddyUnready() > > What if I change accept->online in function names and document the meaning > properly? > >> I assume PageOffline() will be set only on the first sub-page of a >> high-order PageBuddy() page, correct? >> >> Then we'll have to monitor all PageOffline() users such that they can >> actually deal with PageBuddy() pages spanning *multiple* base pages for >> a PageBuddy() page. For now it's clear that if a page is PageOffline(), >> it cannot be PageBuddy() and cannot span more than one base page. > >> E.g., fs/proc/kcore.c:read_kcore() assumes that PageOffline() is set on >> individual base pages. > > Right, pages that offline from hotplug POV are never on page allocator's > free lists, so it cannot ever step on them. > -- Thanks, David / dhildenb