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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 EF338C433E0 for ; Fri, 26 Jun 2020 12:47:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BA37A2078D for ; Fri, 26 Jun 2020 12:47:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA37A2078D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3F5466B0008; Fri, 26 Jun 2020 08:47:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A65A6B000A; Fri, 26 Jun 2020 08:47:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2979E6B000C; Fri, 26 Jun 2020 08:47:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 115346B0008 for ; Fri, 26 Jun 2020 08:47:11 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A03AC181AC9CC for ; Fri, 26 Jun 2020 12:47:10 +0000 (UTC) X-FDA: 76971338220.26.whip59_2910d0226e55 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 7DAA41804A300 for ; Fri, 26 Jun 2020 12:47:10 +0000 (UTC) X-HE-Tag: whip59_2910d0226e55 X-Filterd-Recvd-Size: 5786 Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Fri, 26 Jun 2020 12:47:09 +0000 (UTC) Received: by mail-ed1-f65.google.com with SMTP id dg28so6814743edb.3 for ; Fri, 26 Jun 2020 05:47:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q677LOBSZK3GRaj2PYVKEMW6WT8sZ6D1XkKn5i6DRN8=; b=jviSWQj9hGoKsCW3F4xNna3i+5YwSPuEV7u+zs08w3x6UcpEF2xGpmZpLfsW4YUcqh WM7kmpXCTgSqBRn4+fNY1iuZ9BVNfBozQNA1Qgg7FauPFK86FBtbxanNFw10rTs/LhuZ hyQa6g8jYua9WDs5UyZ3V/5tUzc9ag+cVvESvuOXnIDHrtWG8u1sTQzThftTOIblKn3C 1iORwBydpDHBSAYpg8U2dAzupBk8ShBYg7bvLjYZjTPJx+riYHThN6yt0GkeIrANlQvh cEc55Sb0GeaGZza2up28a6IJ32DjhuVXCULymR+PGFpQxEjNAAYnNThpILxsSwbwcYzP 20Yg== X-Gm-Message-State: AOAM531XXGO5GlWT64Y8MuDqryZP1ZyESfogAni8th5XZ4VPwT95us2k LZLiogSZKLfhtwi9bK0WOk4= X-Google-Smtp-Source: ABdhPJzvRrQp4sNnBeNy5DvIM5p2B4BWpsaztrroQ2rsv/gwu1/HcbrtyIX4R2sLP1GO438dmbsPOA== X-Received: by 2002:a50:f047:: with SMTP id u7mr3373855edl.274.1593175628873; Fri, 26 Jun 2020 05:47:08 -0700 (PDT) Received: from localhost (ip-37-188-168-3.eurotel.cz. [37.188.168.3]) by smtp.gmail.com with ESMTPSA id a62sm21499657ede.45.2020.06.26.05.47.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 05:47:08 -0700 (PDT) Date: Fri, 26 Jun 2020 14:47:06 +0200 From: Michal Hocko To: Daniel Jordan Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Andy Lutomirski , Dave Hansen , David Hildenbrand , Pavel Tatashin , Peter Zijlstra , Steven Sistare Subject: Re: [PATCH v2] x86/mm: use max memory block size on bare metal Message-ID: <20200626124706.GZ1320@dhcp22.suse.cz> References: <20200609225451.3542648-1-daniel.m.jordan@oracle.com> <20200619120704.GD12177@dhcp22.suse.cz> <20200622191739.4lekqrmjnzv2vwl2@ca-dmjordan1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200622191739.4lekqrmjnzv2vwl2@ca-dmjordan1.us.oracle.com> X-Rspamd-Queue-Id: 7DAA41804A300 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 Mon 22-06-20 15:17:39, Daniel Jordan wrote: > Hello Michal, > > (I've been away and may be slow to respond for a little while) > > On Fri, Jun 19, 2020 at 02:07:04PM +0200, Michal Hocko wrote: > > On Tue 09-06-20 18:54:51, Daniel Jordan wrote: > > [...] > > > @@ -1390,6 +1391,15 @@ static unsigned long probe_memory_block_size(void) > > > goto done; > > > } > > > > > > + /* > > > + * Use max block size to minimize overhead on bare metal, where > > > + * alignment for memory hotplug isn't a concern. > > > > This really begs a clarification why this is not a concern. Bare metal > > can see physical memory hotadd as well. I just suspect that you do not > > consider that to be very common so it is not a big deal? > > It's not only uncommon, it's also that boot_mem_end on bare metal may not align > with any available memory block size. For instance, this server's boot_mem_end > is only 4M aligned and FWIW my desktop's is 2M aligned. As far as I can tell, > the logic that picks the size wasn't intended for bare metal. > > > And I would > > tend to agree but still we are just going to wait until first user > > stumbles over this. > > This isn't something new with this patch, 2G has been the default on big > machines for years. This is addressing an unintended side effect of > 078eb6aa50dc50, which was for qemu, by restoring the original behavior on bare > metal to avoid oodles of sysfs files. I am not really sure the qemu was a target. I suspect it was just easier to test in qemu. [...] > > I believe that we should think about a future interface rather than > > trying to ducktape the blocksize anytime it causes problems. I would be > > even tempted to simply add a kernel command line option > > memory_hotplug=disable,legacy,new_shiny > > > > for disable it would simply drop all the sysfs crud and speed up boot > > for most users who simply do not care about memory hotplug. new_shiny > > would ideally provide an interface that would either export logically > > hotplugable memory ranges (e.g. DIMMs) or a query/action interface which > > accepts physical ranges as input. Having gazillions of sysfs files is > > simply unsustainable. > > So in this idea, presumably the default would start off being legacy and then > later be changed to new_shiny? Well it really depends. Going with disable as a default would suit most users much better because the vast majority simply doesn't use the functionality. On the other hand real users would regress unless they enable the option. Which is definitely not nice. Another and much less intrusive change would be creating sysfs interface on-demand. So until somebody actually tries to use the interface it won't exist. I haven't tried to explore how complex that would be. I am not really familiar with sysfs to be honest. But fundamentally nothing should prevent such a solution. Another option would be to create sysfs interface only if there is a hotplugable memory reported by the platform. But I am not sure we have a proper interface for that for all arches. -- Michal Hocko SUSE Labs