From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by kanga.kvack.org (Postfix) with ESMTP id 3BEA66B026D for ; Fri, 5 Oct 2018 03:37:55 -0400 (EDT) Received: by mail-qt1-f198.google.com with SMTP id j60-v6so3703627qtb.8 for ; Fri, 05 Oct 2018 00:37:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id o69-v6si3380701qkh.108.2018.10.05.00.37.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 00:37:54 -0700 (PDT) Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types References: <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> <8736tndubn.fsf@vitty.brq.redhat.com> <20181003134444.GH4714@dhcp22.suse.cz> <87zhvvcf3b.fsf@vitty.brq.redhat.com> <49456818-238e-2d95-9df6-d1934e9c8b53@linux.intel.com> <87tvm3cd5w.fsf@vitty.brq.redhat.com> <06a35970-e478-18f8-eae6-4022925a5192@redhat.com> <20181004061938.GB22173@dhcp22.suse.cz> <20181004172807.1eef3a6b@kitsune.suse.cz> <14992b68-5402-9168-0050-b3c6ac4a8c90@redhat.com> <20181004195010.3616fc40@kitsune.suse.cz> From: David Hildenbrand Message-ID: Date: Fri, 5 Oct 2018 09:37:39 +0200 MIME-Version: 1.0 In-Reply-To: <20181004195010.3616fc40@kitsune.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: =?UTF-8?Q?Michal_Such=c3=a1nek?= Cc: Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Dave Hansen , Heiko Carstens , Michal Hocko , linux-mm@kvack.org, Paul Mackerras , "H. Peter Anvin" , Rashmica Gupta , Boris Ostrovsky , Stephen Rothwell , Michael Neuling , Stephen Hemminger , Yoshinori Sato , Vitaly Kuznetsov , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Rob Herring , Len Brown , Pavel Tatashin , linux-s390@vger.kernel.org, "mike.travis@hpe.com" , Haiyang Zhang , =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= , Nicholas Piggin , Joe Perches , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Mike Rapoport , Borislav Petkov , Andy Lutomirski , Dan Williams , Andrew Morton , Oscar Salvador , Juergen Gross , Tony Luck , Mathieu Malaterre , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Fenghua Yu , Mauricio Faria de Oliveira , Thomas Gleixner , Philippe Ombredanne , Martin Schwidefsky , devel@linuxdriverproject.org, Joonsoo Kim , linuxppc-dev@lists.ozlabs.org, "Kirill A. Shutemov" On 04/10/2018 19:50, Michal SuchA!nek wrote: > On Thu, 4 Oct 2018 17:45:13 +0200 > David Hildenbrand wrote: > >> On 04/10/2018 17:28, Michal SuchA!nek wrote: > >>> >>> The state of the art is to determine what to do with hotplugged >>> memory in userspace based on platform and virtualization type. >> >> Exactly. >> >>> >>> Changing the default to depend on the driver that added the memory >>> rather than platform type should solve the issue of VMs growing >>> different types of memory device emulation. >> >> Yes, my original proposal (this patch) was to handle it in the kernel >> for known types. But as we learned, there might be some use cases that >> might still require to make a decision in user space. >> >> So providing the user space either with some type hint (auto-online >> vs. standby) or the driver that added it (system vs. hyper-v ...) >> would solve the issue. > > Is that not available in the udev event? > Not that I am aware. Memory blocks "devices" have no drivers. ls -la /sys/devices/system/memory/memory0/subsystem/drivers total 0 (add_memory()/add_memory_resource() creates the memory block devices when called from a driver) > Thanks > > Michal > -- Thanks, David / dhildenb