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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 170DBC433EF for ; Wed, 29 Sep 2021 12:12:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CA1526138E for ; Wed, 29 Sep 2021 12:12:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CA1526138E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5/nZ088PRGE1HvYyGOgQ3PYUaoqDak5UaPgk3kdEknI=; b=WK0s6sshaUwtSxBtXyj43v0OI3 B3rJlP4y73y2QLsFD+pDp+g2aN63OwPJ2qzxEARO22gRLp16E5t0LEgfVcvDNcnWDE1iZR9GOTSip nFh+UeGAe5lCiC/RXj2DVfSiTw7xQ4VP+ckg92DgdvsuSF8u95UQcWbgw7Vdj2L+SXiSLzlDGsXC5 rtp7CgwbKftm4IJ52v4xsQRWPN0B5yN3P61ryjHtu0RLVQ4eyFngQURQ4GzQwPdFnzjNs9OqcvIRV Y5vktXPMnCE9kOK6J5wUgUhUv74DUwmP69iFD28pXYNyklq8IILcTRfY83SD0h2yGFw2gNSa1AsUd FisjuusQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVYPE-00Az1X-E8; Wed, 29 Sep 2021 12:09:49 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVYP7-00Az06-BQ for linux-arm-kernel@lists.infradead.org; Wed, 29 Sep 2021 12:09:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632917379; 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=m4DcsmdERvwEayP8lS8c/q6o204OALA6BwCBR3wwYSU=; b=gWQlriBpZCtOuAsqg9rPZBMg8RgcO3xXQQMe4tXi0sZB2414NsGls7zz3ZTc4R6Gs4kMUJ 2gbktftyQ8OcLsDBQrMDMU64K3YBdlAh8KPV08AWme6xWn9pcp870MvMjVGg2j1HbUn+7b IsDsRlaSkYN78gxRsCJW0eo4mt4mVR0= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-469-EXDEGNaFNrGXeKBAuwYyrQ-1; Wed, 29 Sep 2021 08:09:38 -0400 X-MC-Unique: EXDEGNaFNrGXeKBAuwYyrQ-1 Received: by mail-wm1-f71.google.com with SMTP id 129-20020a1c1987000000b0030cd1616fbfso2621172wmz.3 for ; Wed, 29 Sep 2021 05:09:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=m4DcsmdERvwEayP8lS8c/q6o204OALA6BwCBR3wwYSU=; b=KhtFUNFA71gc9X6Xvf2MuMeOteubzuKpESqc+6LzRE6UIF96veRYvuxeujfVW9XzcV tDt//UAzfOuIK5Hz0Kjt21vFlJ+BQYeedoR16eI+2eXu9iepxSyrKPEzg8YwV0xe+MX7 ssUcngo+MKSoJ8AGiglNX6CSb3jrQuQpDJT9CuHjQF/0jWLLM/5E6M1D8HKP3l4mjptM zRi//YJajnTy7/XluwwOttWIooBMHpIGhji7RUYmTbRBzi0ra6YlWn0F3g2iq2i96zIE oLsCH2LV5Wg5DAKr/mdGkO5MCcTEeSGtmnbiey881UWCEsAso83hgCg53ifp82HnEant Tr1Q== X-Gm-Message-State: AOAM533FzkiBXJue9Si6jIYDXmQWHHcvxX3ZCtbRahgaBj8wZe265GBi sY8LdWNN0dKq/absQX9ALbMBIX7lfVd+ycKv7qnHJHll+SUdixAhoUvBZMYrWJgWVuZ+QjwsHWJ DMT7KKvQNgky2DSpuAv/mNsnSnAe0UdQyfqs= X-Received: by 2002:a7b:c1d6:: with SMTP id a22mr9983253wmj.146.1632917377437; Wed, 29 Sep 2021 05:09:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEQO6IjIjiX7wFN2+HDTboYoYk/OTp98F2ya3lRO8pW+OuQGAUAEkqR2bTjtD2aDDY3KEI+g== X-Received: by 2002:a7b:c1d6:: with SMTP id a22mr9983226wmj.146.1632917377186; Wed, 29 Sep 2021 05:09:37 -0700 (PDT) Received: from [192.168.3.132] (p4ff23c3b.dip0.t-ipconnect.de. [79.242.60.59]) by smtp.gmail.com with ESMTPSA id u1sm1391208wmc.29.2021.09.29.05.09.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Sep 2021 05:09:36 -0700 (PDT) To: Will Deacon Cc: Chris Goldsworthy , Catalin Marinas , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sudarshan Rajagopalan References: <595d09279824faf1f54961cef52b745609b05d97.1632437225.git.quic_cgoldswo@quicinc.com> <20210929101028.GB21057@willie-the-truck> <13f56b37-afc7-bf6f-d544-8d6433588bf9@redhat.com> <20210929104241.GA21395@willie-the-truck> <20210929110339.GA21510@willie-the-truck> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC] arm64: mm: update max_pfn after memory hotplug Message-ID: <130a50d7-92fd-31fa-261e-f73dadcb4fcf@redhat.com> Date: Wed, 29 Sep 2021 14:09:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210929110339.GA21510@willie-the-truck> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210929_050941_528196_AF0FCF54 X-CRM114-Status: GOOD ( 25.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 29.09.21 13:03, Will Deacon wrote: > On Wed, Sep 29, 2021 at 12:49:58PM +0200, David Hildenbrand wrote: >> On 29.09.21 12:42, Will Deacon wrote: >>> On Wed, Sep 29, 2021 at 12:29:32PM +0200, David Hildenbrand wrote: >>>> On 29.09.21 12:10, Will Deacon wrote: >>>>> On Thu, Sep 23, 2021 at 03:54:48PM -0700, Chris Goldsworthy wrote: >>>>>> From: Sudarshan Rajagopalan >>>>>> >>>>>> After new memory blocks have been hotplugged, max_pfn and max_low_pfn >>>>>> needs updating to reflect on new PFNs being hot added to system. >>>>>> >>>>>> Signed-off-by: Sudarshan Rajagopalan >>>>>> Signed-off-by: Chris Goldsworthy >>>>>> --- >>>>>> arch/arm64/mm/mmu.c | 5 +++++ >>>>>> 1 file changed, 5 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >>>>>> index cfd9deb..fd85b51 100644 >>>>>> --- a/arch/arm64/mm/mmu.c >>>>>> +++ b/arch/arm64/mm/mmu.c >>>>>> @@ -1499,6 +1499,11 @@ int arch_add_memory(int nid, u64 start, u64 size, >>>>>> if (ret) >>>>>> __remove_pgd_mapping(swapper_pg_dir, >>>>>> __phys_to_virt(start), size); >>>>>> + else { >>>>>> + max_pfn = PFN_UP(start + size); >>>>>> + max_low_pfn = max_pfn; >>>>>> + } >>>>> >>>>> We use 'max_pfn' as part of the argument to set_max_mapnr(). Does that need >>>>> updating as well? >>>>> >>>>> Do we have sufficient locking to ensure nobody is looking at max_pfn or >>>>> max_low_pfn while we update them? >>>> >>>> Only the write side is protected by memory hotplug locking. The read side is >>>> lockless -- just like all of the other pfn_to_online_page() machinery. >>> >>> Hmm. So the readers can see one of the variables updated but the other one >>> stale? >> >> Yes, just like it has been on x86-64 for a long time: >> >> arch/x86/mm/init_64.c:update_end_of_memory_vars() >> >> Not sure if anyone really cares about slightly delayed updates while memory >> is getting hotplugged. The users that I am aware of don't care. > > Thanks, I'd missed that x86 also updates max_low_pfn. So at least we're not > worse off in that respect. > > Looking at set_max_mapnr(), I'm wondering why we need to call that at all > on arm64 as 'max_mapnr' only seems to be used for nommu. I think max_mapnr is only helpful without SPARSE, I can spot the most prominent consumer being simplistic pfn_valid() implementation. MEMORY_HOTPLUG on arm64 implies SPARSE. ... and I recall that FLATMEM is no longer possible on arm64. So most probably the arm64 call of set_max_mapnr() can just be dropped. -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel