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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,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 6F770C433DB for ; Thu, 18 Mar 2021 12:05:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D4EB964F2A for ; Thu, 18 Mar 2021 12:05:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4EB964F2A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5B3186B0070; Thu, 18 Mar 2021 08:05:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 577706B0071; Thu, 18 Mar 2021 08:05:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 418A46B0072; Thu, 18 Mar 2021 08:05:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id 28F9F6B0070 for ; Thu, 18 Mar 2021 08:05:53 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DF73545BC for ; Thu, 18 Mar 2021 12:05:52 +0000 (UTC) X-FDA: 77932866144.32.E7F310A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf20.hostedemail.com (Postfix) with ESMTP id DFA6BF7 for ; Thu, 18 Mar 2021 12:05:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616069149; 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=/xveODCKicquk1mCJcnO2rTTzMf/rWshKRdhXeN4fxg=; b=LPgP3M6JmbwLdL1FfKAFzK1IhDRrhjDbQ5JympOHBRrcq8LtVt4fM4ZEY+1ug1uyZWC/5A R+KceHNhAJi5LZPpEZMuolihw2C/7fCx6mjD8sLuCozJtgutGB5PEWoWsxXIkoNUhVMExj fOwOXtIIMYgt965h5wLlMrcx3jc+l0k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-441-OsMGj_RlPkGMJNRT4kHWKA-1; Thu, 18 Mar 2021 08:05:46 -0400 X-MC-Unique: OsMGj_RlPkGMJNRT4kHWKA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5CA7D107B7C3; Thu, 18 Mar 2021 12:05:44 +0000 (UTC) Received: from [10.36.113.61] (ovpn-113-61.ams2.redhat.com [10.36.113.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id C1A0B10016FC; Thu, 18 Mar 2021 12:05:40 +0000 (UTC) Subject: Re: [PATCH v4 1/5] mm,memory_hotplug: Allocate memmap from the added memory range To: Oscar Salvador Cc: Andrew Morton , Michal Hocko , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210309175546.5877-2-osalvador@suse.de> <20210315102224.GA24699@linux> <20210317140847.GA20407@linux> <51c645b3-1220-80c4-e44c-4c0411222148@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Thu, 18 Mar 2021 13:05:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DFA6BF7 X-Stat-Signature: 8xwd85pqu9za9sjnirbswrm1fpaw9b97 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616069151-691287 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 18.03.21 13:03, Oscar Salvador wrote: > On Thu, Mar 18, 2021 at 12:24:16PM +0100, David Hildenbrand wrote: >> I don't follow. 2MB == 2MB. And if there would be difference then we would >> be in the problem I brought up: vmemmap code allocating too much via the >> altmap, which can be very bad because might be populating more vmemmap than >> we actually need. > > Yes, I meant to say nr_vmemmap_pages won't match, or IOW, won't have the > same meaning. > The end result is the same. > >> vmemmap_size = 512 * 4KiB = 2 MiB. >> >> That calculation wasn't very useful (/ PAGE_SIZE * PAGE_SIZE)? > > Yeah, somewhat redundant. > >> >>> unsigned long remaining_size = size - vmemmap_size; >> >> And here we could get something like >> >> remaining_size = 2 GiB - 2 MiB > > Yes, vmemmap_size would need to scale with nr_sections to be relative to > size. > > Just wanted to bring it up, because somene might wonder > "ok, why do we have altmap->nr_pfns = X, and here nr_vmemmap_pages > is Y" > > It was an effort to make it consistent, although I see it would bring > more confusion other than anything, so disregard. I am also unhappy that we have to replicate the same computation at two places, but I don't see an easy way to avoid that ... we have to trust on vmemmap code to do the right thing either way :( -- Thanks, David / dhildenb