From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by kanga.kvack.org (Postfix) with ESMTP id 271616B0269 for ; Thu, 4 Oct 2018 11:45:29 -0400 (EDT) Received: by mail-qt1-f200.google.com with SMTP id f19-v6so8644422qtp.6 for ; Thu, 04 Oct 2018 08:45:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id b86-v6si3538825qkh.45.2018.10.04.08.45.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 08:45:28 -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> From: David Hildenbrand Message-ID: <14992b68-5402-9168-0050-b3c6ac4a8c90@redhat.com> Date: Thu, 4 Oct 2018 17:45:13 +0200 MIME-Version: 1.0 In-Reply-To: <20181004172807.1eef3a6b@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: Michal Hocko , Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Dave Hansen , Heiko Carstens , linux-mm@kvack.org, Paul Mackerras , "H. Peter Anvin" , Stephen Rothwell , Rashmica Gupta , Dan Williams , linux-s390@vger.kernel.org, Michael Neuling , Stephen Hemminger , Yoshinori Sato , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Len Brown , Pavel Tatashin , Rob Herring , "mike.travis@hpe.com" , Haiyang Zhang , =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= , Nicholas Piggin , Martin Schwidefsky , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Mike Rapoport , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , Joonsoo Kim , Oscar Salvador , Juergen Gross , Tony Luck , Andrew Morton , Mathieu Malaterre , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Fenghua Yu , Mauricio Faria de Oliveira , Thomas Gleixner , Philippe Ombredanne , Joe Perches , devel@linuxdriverproject.org, Vitaly Kuznetsov , linuxppc-dev@lists.ozlabs.org, "Kirill A. Shutemov" On 04/10/2018 17:28, Michal SuchA!nek wrote: > On Thu, 4 Oct 2018 10:13:48 +0200 > David Hildenbrand wrote: > > ok, so what is the problem here? > > Handling the hotplug in userspace through udev may be suboptimal and > kernel handling might be faster but that's orthogonal to the problem at > hand. Yes, that one to solve is a different story. > > 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. > > Am I missing something? > No, that's it. Thanks! > Thanks > > Michal > -- Thanks, David / dhildenb