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.2 required=3.0 tests=BAYES_00, 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 7367EC433E3 for ; Thu, 23 Jul 2020 12:28:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4026320888 for ; Thu, 23 Jul 2020 12:28:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4026320888 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BBB7E6B0002; Thu, 23 Jul 2020 08:28:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B44166B0005; Thu, 23 Jul 2020 08:28:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A33076B0006; Thu, 23 Jul 2020 08:28:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id 88C526B0002 for ; Thu, 23 Jul 2020 08:28:16 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1A6EE1802E634 for ; Thu, 23 Jul 2020 12:28:16 +0000 (UTC) X-FDA: 77069268192.18.cap25_05140e726f3e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id D776710048BD2 for ; Thu, 23 Jul 2020 12:28:15 +0000 (UTC) X-HE-Tag: cap25_05140e726f3e X-Filterd-Recvd-Size: 4767 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Jul 2020 12:28:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id F2008AAC5; Thu, 23 Jul 2020 12:28:21 +0000 (UTC) Subject: Re: [PATCH 3/3] memory: introduce an option to force onlining of hotplug memory To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , David Hildenbrand Cc: linux-kernel@vger.kernel.org, Boris Ostrovsky , Stefano Stabellini , Andrew Morton , xen-devel@lists.xenproject.org, linux-mm@kvack.org References: <20200723084523.42109-1-roger.pau@citrix.com> <20200723084523.42109-4-roger.pau@citrix.com> <21490d49-b2cf-a398-0609-8010bdb0b004@redhat.com> <20200723122300.GD7191@Air-de-Roger> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <404ea76f-c3d8-dbc5-432d-08d84a17f2d7@suse.com> Date: Thu, 23 Jul 2020 14:28:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200723122300.GD7191@Air-de-Roger> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Queue-Id: D776710048BD2 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 Content-Transfer-Encoding: quoted-printable 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 23.07.20 14:23, Roger Pau Monn=C3=A9 wrote: > On Thu, Jul 23, 2020 at 01:37:03PM +0200, David Hildenbrand wrote: >> On 23.07.20 10:45, Roger Pau Monne wrote: >>> Add an extra option to add_memory_resource that overrides the memory >>> hotplug online behavior in order to force onlining of memory from >>> add_memory_resource unconditionally. >>> >>> This is required for the Xen balloon driver, that must run the >>> online page callback in order to correctly process the newly added >>> memory region, note this is an unpopulated region that is used by Lin= ux >>> to either hotplug RAM or to map foreign pages from other domains, and >>> hence memory hotplug when running on Xen can be used even without the >>> user explicitly requesting it, as part of the normal operations of th= e >>> OS when attempting to map memory from a different domain. >>> >>> Setting a different default value of memhp_default_online_type when >>> attaching the balloon driver is not a robust solution, as the user (o= r >>> distro init scripts) could still change it and thus break the Xen >>> balloon driver. >> >> I think we discussed this a couple of times before (even triggered by = my >> request), and this is responsibility of user space to configure. Usual= ly >> distros have udev rules to online memory automatically. Especially, us= er >> space should eb able to configure *how* to online memory. >=20 > Note (as per the commit message) that in the specific case I'm > referring to the memory hotplugged by the Xen balloon driver will be > an unpopulated range to be used internally by certain Xen subsystems, > like the xen-blkback or the privcmd drivers. The addition of such > blocks of (unpopulated) memory can happen without the user explicitly > requesting it, and hence not even aware such hotplug process is taking > place. To be clear: no actual RAM will be added to the system. >=20 > Failure to online such blocks using the Xen specific online handler > (which does not handle back the memory to the allocator in any way) > will result in the system getting stuck and malfunctioning. >=20 >> It's the admin/distro responsibility to configure this properly. In ca= se >> this doesn't happen (or as you say, users change it), bad luck. >> >> E.g., virtio-mem takes care to not add more memory in case it is not >> getting onlined. I remember hyper-v has similar code to at least wait = a >> bit for memory to get onlined. >=20 > I don't think VirtIO or Hyper-V use the hotplug system in the same way > as Xen, as said this is done to add unpopulated memory regions that > will be used to map foreign memory (from other domains) by Xen drivers > on the system. >=20 > Maybe this should somehow use a different mechanism to hotplug such > empty memory blocks? I don't mind doing this differently, but I would > need some pointers. Allowing user-space to change a (seemingly > unrelated) parameter and as a result produce failures on Xen drivers > is not an acceptable solution IMO. Maybe we can use the same approach as Xen PV-domains: pre-allocate a region in the memory map to be used for mapping foreign pages. For the kernel it will look like pre-ballooned memory, so it will create struct page for the region (which is what we are after), but it won't give the memory to the allocator. Juergen