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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 436E4C32753 for ; Wed, 31 Jul 2019 13:12:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F2B92208E4 for ; Wed, 31 Jul 2019 13:12:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2B92208E4 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 8AC858E0003; Wed, 31 Jul 2019 09:12:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 883168E0001; Wed, 31 Jul 2019 09:12:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 771658E0003; Wed, 31 Jul 2019 09:12:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by kanga.kvack.org (Postfix) with ESMTP id 563758E0001 for ; Wed, 31 Jul 2019 09:12:17 -0400 (EDT) Received: by mail-qt1-f198.google.com with SMTP id d26so61572728qte.19 for ; Wed, 31 Jul 2019 06:12:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:subject:to:cc :references:from:openpgp:autocrypt:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FzrR9WANIL0CDar/dYamdFwc5nU2Pz9QyW7W0O/mVJs=; b=XL+NAeyzALus9rby6Y+nDtqd1m4dvtPs71T6AAMZd+fw4N37HD2D75Hwld4b4ACiP5 puE5qt82ojba9Ic7mV6vFmCQ8OUhCQSlR2DMw2CTnMYXhb/jV6CjeTMxhjYl3VjuIIPA HoR6ifbpe/kbfinmvgzV8d/Rn4TogSEpLncwDiQs01qKVDQxtkxYJ9ueZZBstLf/ywTK zpCC8BJriVp+5AuqJcZW3nmV+h42Yoduwx3kPDRZd/qBKqcmTSDfoScVpNV/ESptAUlj E27VBK4S4uTy9YNZYuQNnOkB1+vVEXKO3lORkJWMMOFFaV95C9W9+razC0X4mdOiCACf THlw== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: APjAAAXmTuO3gR7AVDQ55o4YMpXEzMWY9mvMdgCZ6Z5IfBQqu284uZtL BXnfY0STS6cGSeuaQ8FWEvj8luYiKrF5+M4aio7WW3+QR9QWPNuTCn4FArxU0FTp3XmC4ANgzOW 7Rb1GvND0sghgVkxMyQLYoF709ltSTQX2Qmz99ZjWOoBcRfZX3vpdkIq2A6hK7fGx7g== X-Received: by 2002:a0c:99e9:: with SMTP id y41mr85974167qve.186.1564578737111; Wed, 31 Jul 2019 06:12:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqwwsOC2OILgbJj7m7Qvwz2GmRFdAWnsFbLRzaG+CXkelt4Jx9JiOd1WYMCbsTIofkel5u1A X-Received: by 2002:a0c:99e9:: with SMTP id y41mr85974110qve.186.1564578736402; Wed, 31 Jul 2019 06:12:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564578736; cv=none; d=google.com; s=arc-20160816; b=tIGUjdn7ZB8CV2iSH3J9stInkBm5uAFo83QpoR4OYD29cPTchc+WSVcEuVryUeUNvD 22CaHT+umDLYNYKbpCyb++oAquiD/3PljqHeYoXwYTmSun1zO4zm2uE9zRFQp5Mt2Dr8 bxn7K7oVEU4ey1GkDP8Pa1GeVqKTzWx/TDzx1FTcW+sYMh/7LNI6G0dGKjm1uG1i/znK m/jbKjB0qlHNtJ0SZpYIOxXdS6i4dhPKLG4JUL4APO7EUaBfLjfQSxUV/7p8Dhc7tsP5 R4fTBYWWU/cmizFCVo7kMPTTNmTupJ+HeNQ2dohBJJx+Hu5WycjJ3xbdQJeZnzMDlko2 PfRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:organization:autocrypt:openpgp:from :references:cc:to:subject; bh=FzrR9WANIL0CDar/dYamdFwc5nU2Pz9QyW7W0O/mVJs=; b=fatDYRobtmFhCWybANpWLHa2i46EGqd2yhSSNS5jQjTY2AuSQQfgwmiSnBIzuEaSqR BLm2gMKhHNPJjTrPXvmXtluJOUpfwV+Cc+IJtLNU1IhYlLfW6DK7iEvPNbqKwEBNgg2b x+MaBVy7mBPIiMSUVf28MCTaHRh4nrw0J+EcQ+kT0ddwYsg0mEaE1Y4QebvypbfgkrI4 /oOus3fBUj1YGJ0qR5aBTP3Rard1KYRS5JWR2WiutWfXjcAceGhUr5RQwiArYEUyVgUX pyucoAkzziM2CaL2CwBbl33Za43ac4DjE4W6cxFUT3wRjE86LHZSTbmkDFHPUU+1EmWl U06Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id h4si37143276qkj.296.2019.07.31.06.12.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 06:12:16 -0700 (PDT) Received-SPF: pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Authentication-Results: mx.google.com; spf=pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7FFAE3B77; Wed, 31 Jul 2019 13:12:15 +0000 (UTC) Received: from [10.36.117.240] (ovpn-117-240.ams2.redhat.com [10.36.117.240]) by smtp.corp.redhat.com (Postfix) with ESMTP id 69E9B5C1B5; Wed, 31 Jul 2019 13:12:13 +0000 (UTC) Subject: Re: [PATCH v1] drivers/base/memory.c: Don't store end_section_nr in memory blocks To: Michal Hocko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Andrew Morton , Pavel Tatashin , Dan Williams , Oscar Salvador References: <20190731122213.13392-1-david@redhat.com> <20190731124356.GL9330@dhcp22.suse.cz> From: David Hildenbrand Openpgp: preference=signencrypt Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwX4EEwECACgFAljj9eoCGwMFCQlmAYAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEE3eEPcA/4Na5IIP/3T/FIQMxIfNzZshIq687qgG 8UbspuE/YSUDdv7r5szYTK6KPTlqN8NAcSfheywbuYD9A4ZeSBWD3/NAVUdrCaRP2IvFyELj xoMvfJccbq45BxzgEspg/bVahNbyuBpLBVjVWwRtFCUEXkyazksSv8pdTMAs9IucChvFmmq3 jJ2vlaz9lYt/lxN246fIVceckPMiUveimngvXZw21VOAhfQ+/sofXF8JCFv2mFcBDoa7eYob s0FLpmqFaeNRHAlzMWgSsP80qx5nWWEvRLdKWi533N2vC/EyunN3HcBwVrXH4hxRBMco3jvM m8VKLKao9wKj82qSivUnkPIwsAGNPdFoPbgghCQiBjBe6A75Z2xHFrzo7t1jg7nQfIyNC7ez MZBJ59sqA9EDMEJPlLNIeJmqslXPjmMFnE7Mby/+335WJYDulsRybN+W5rLT5aMvhC6x6POK z55fMNKrMASCzBJum2Fwjf/VnuGRYkhKCqqZ8gJ3OvmR50tInDV2jZ1DQgc3i550T5JDpToh dPBxZocIhzg+MBSRDXcJmHOx/7nQm3iQ6iLuwmXsRC6f5FbFefk9EjuTKcLMvBsEx+2DEx0E UnmJ4hVg7u1PQ+2Oy+Lh/opK/BDiqlQ8Pz2jiXv5xkECvr/3Sv59hlOCZMOaiLTTjtOIU7Tq 7ut6OL64oAq+zsFNBFXLn5EBEADn1959INH2cwYJv0tsxf5MUCghCj/CA/lc/LMthqQ773ga uB9mN+F1rE9cyyXb6jyOGn+GUjMbnq1o121Vm0+neKHUCBtHyseBfDXHA6m4B3mUTWo13nid 0e4AM71r0DS8+KYh6zvweLX/LL5kQS9GQeT+QNroXcC1NzWbitts6TZ+IrPOwT1hfB4WNC+X 2n4AzDqp3+ILiVST2DT4VBc11Gz6jijpC/KI5Al8ZDhRwG47LUiuQmt3yqrmN63V9wzaPhC+ xbwIsNZlLUvuRnmBPkTJwwrFRZvwu5GPHNndBjVpAfaSTOfppyKBTccu2AXJXWAE1Xjh6GOC 8mlFjZwLxWFqdPHR1n2aPVgoiTLk34LR/bXO+e0GpzFXT7enwyvFFFyAS0Nk1q/7EChPcbRb hJqEBpRNZemxmg55zC3GLvgLKd5A09MOM2BrMea+l0FUR+PuTenh2YmnmLRTro6eZ/qYwWkC u8FFIw4pT0OUDMyLgi+GI1aMpVogTZJ70FgV0pUAlpmrzk/bLbRkF3TwgucpyPtcpmQtTkWS gDS50QG9DR/1As3LLLcNkwJBZzBG6PWbvcOyrwMQUF1nl4SSPV0LLH63+BrrHasfJzxKXzqg rW28CTAE2x8qi7e/6M/+XXhrsMYG+uaViM7n2je3qKe7ofum3s4vq7oFCPsOgwARAQABwsFl BBgBAgAPBQJVy5+RAhsMBQkJZgGAAAoJEE3eEPcA/4NagOsP/jPoIBb/iXVbM+fmSHOjEshl KMwEl/m5iLj3iHnHPVLBUWrXPdS7iQijJA/VLxjnFknhaS60hkUNWexDMxVVP/6lbOrs4bDZ NEWDMktAeqJaFtxackPszlcpRVkAs6Msn9tu8hlvB517pyUgvuD7ZS9gGOMmYwFQDyytpepo YApVV00P0u3AaE0Cj/o71STqGJKZxcVhPaZ+LR+UCBZOyKfEyq+ZN311VpOJZ1IvTExf+S/5 lqnciDtbO3I4Wq0ArLX1gs1q1XlXLaVaA3yVqeC8E7kOchDNinD3hJS4OX0e1gdsx/e6COvy qNg5aL5n0Kl4fcVqM0LdIhsubVs4eiNCa5XMSYpXmVi3HAuFyg9dN+x8thSwI836FoMASwOl C7tHsTjnSGufB+D7F7ZBT61BffNBBIm1KdMxcxqLUVXpBQHHlGkbwI+3Ye+nE6HmZH7IwLwV W+Ajl7oYF+jeKaH4DZFtgLYGLtZ1LDwKPjX7VAsa4Yx7S5+EBAaZGxK510MjIx6SGrZWBrrV TEvdV00F2MnQoeXKzD7O4WFbL55hhyGgfWTHwZ457iN9SgYi1JLPqWkZB0JRXIEtjd4JEQcx +8Umfre0Xt4713VxMygW0PnQt5aSQdMD58jHFxTk092mU+yIHj5LeYgvwSgZN4airXk5yRXl SE+xAvmumFBY Organization: Red Hat GmbH Message-ID: Date: Wed, 31 Jul 2019 15:12:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190731124356.GL9330@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 31 Jul 2019 13:12:15 +0000 (UTC) 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 31.07.19 14:43, Michal Hocko wrote: > On Wed 31-07-19 14:22:13, David Hildenbrand wrote: >> Each memory block spans the same amount of sections/pages/bytes. The size >> is determined before the first memory block is created. No need to store >> what we can easily calculate - and the calculations even look simpler now. > > While this cleanup helps a bit, I am not sure this is really worth > bothering. I guess we can agree when I say that the memblock interface > is suboptimal (to put it mildly). Shouldn't we strive for making it > a real hotplug API in the future? What do I mean by that? Why should > be any memblock fixed in size? Shouldn't we have use hotplugable units > instead (aka pfn range that userspace can work with sensibly)? Do we > know of any existing userspace that would depend on the current single > section res. 2GB sized memblocks? Short story: It is already ABI (e.g., /sys/devices/system/memory/block_size_bytes) - around since 2005 (!) - since we had memory block devices. I suspect that it is mainly manually used. But I might be wrong. Long story: How would you want to number memory blocks? At least no longer by phys index. For now, memory blocks are ordered and numbered by their block id. Admins might want to online parts of a DIMM MOVABLE/NORMAL, to more reliably use huge pages but still have enough space for kernel memory (e.g., page tables). They might like that a DIMM is actually a set of memory blocks instead of one big chunk. IOW: You can consider it a restriction to add e.g., DIMMs only in one bigger chunks. > > All that being said, I do not oppose to the patch but can we start > thinking about the underlying memblock limitations rather than micro > cleanups? I am pro cleaning up what we have right now, not expect it to eventually change some-when in the future. (btw, I highly doubt it will change) -- Thanks, David / dhildenb