From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Date: Thu, 4 Oct 2018 08:28:11 +0200 Message-ID: <20181004062811.GC22173@dhcp22.suse.cz> References: <20180928150357.12942-1-david@redhat.com> <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> <20181003135407.GI4714@dhcp22.suse.cz> <9fef1f7d-2d7c-03f1-00e3-5fa657eda019@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <9fef1f7d-2d7c-03f1-00e3-5fa657eda019@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: David Hildenbrand Cc: Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Benjamin Herrenschmidt , Balbir Singh , Dave Hansen , Heiko Carstens , linux-mm@kvack.org, Pavel Tatashin , Paul Mackerras , "H. Peter Anvin" , Rashmica Gupta , Boris Ostrovsky , linux-s390@vger.kernel.org, Michael Neuling , Stephen Hemminger , Yoshinori Sato , Michael Ellerman , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Rob Herring List-Id: linux-acpi@vger.kernel.org On Wed 03-10-18 19:00:29, David Hildenbrand wrote: [...] > Let me rephrase: You state that user space has to make the decision and > that user should be able to set/reconfigure rules. That is perfectly fine. > > But then we should give user space access to sufficient information to > make a decision. This might be the type of memory as we learned (what > some part of this patch proposes), but maybe later more, e.g. to which > physical device memory belongs (e.g. to hotplug it all movable or all > normal) ... I am pretty sure that user knows he/she wants to use ballooning in HyperV or Xen, or that the memory hotplug should be used as a "RAS" feature to allow add and remove DIMMs for reliability. Why shouldn't we have a package to deploy an appropriate set of udev rules for each of those usecases? I am pretty sure you need some other plumbing to enable them anyway (e.g. RAS would require to have movable_node kernel parameters, ballooning a kernel module etc.). Really, one udev script to rule them all will simply never work. -- Michal Hocko SUSE Labs 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.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham 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 6B45DC64EB8 for ; Thu, 4 Oct 2018 07:03:48 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B5CC721470 for ; Thu, 4 Oct 2018 07:03:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B5CC721470 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 42QkPt0sBvzF3J3 for ; Thu, 4 Oct 2018 17:03:46 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; spf=softfail (mailfrom) smtp.mailfrom=kernel.org (client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=mhocko@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=kernel.org Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42Qjcy0v4FzF3D0 for ; Thu, 4 Oct 2018 16:28:18 +1000 (AEST) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 931DAB07A; Thu, 4 Oct 2018 06:28:14 +0000 (UTC) Date: Thu, 4 Oct 2018 08:28:11 +0200 From: Michal Hocko To: David Hildenbrand Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Message-ID: <20181004062811.GC22173@dhcp22.suse.cz> References: <20180928150357.12942-1-david@redhat.com> <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> <20181003135407.GI4714@dhcp22.suse.cz> <9fef1f7d-2d7c-03f1-00e3-5fa657eda019@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fef1f7d-2d7c-03f1-00e3-5fa657eda019@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Dave Hansen , Heiko Carstens , linux-mm@kvack.org, Pavel Tatashin , Paul Mackerras , "H. Peter Anvin" , Rashmica Gupta , "K. Y. Srinivasan" , Boris Ostrovsky , linux-s390@vger.kernel.org, Michael Neuling , Stephen Hemminger , Yoshinori Sato , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Rob Herring , Len Brown , Fenghua Yu , Stephen Rothwell , "mike.travis@hpe.com" , Haiyang Zhang , Dan Williams , Jonathan =?iso-8859-1?Q?Neusch=E4fer?= , Nicholas Piggin , Joe Perches , =?iso-8859-1?B?Suly9G1l?= Glisse , Mike Rapoport , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Joonsoo Kim , Oscar Salvador , Juergen Gross , Tony Luck , Mathieu Malaterre , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Mauricio Faria de Oliveira , Philippe Ombredanne , Martin Schwidefsky , devel@linuxdriverproject.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, "Kirill A. Shutemov" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed 03-10-18 19:00:29, David Hildenbrand wrote: [...] > Let me rephrase: You state that user space has to make the decision and > that user should be able to set/reconfigure rules. That is perfectly fine. > > But then we should give user space access to sufficient information to > make a decision. This might be the type of memory as we learned (what > some part of this patch proposes), but maybe later more, e.g. to which > physical device memory belongs (e.g. to hotplug it all movable or all > normal) ... I am pretty sure that user knows he/she wants to use ballooning in HyperV or Xen, or that the memory hotplug should be used as a "RAS" feature to allow add and remove DIMMs for reliability. Why shouldn't we have a package to deploy an appropriate set of udev rules for each of those usecases? I am pretty sure you need some other plumbing to enable them anyway (e.g. RAS would require to have movable_node kernel parameters, ballooning a kernel module etc.). Really, one udev script to rule them all will simply never work. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 5792E6B000A for ; Thu, 4 Oct 2018 02:28:18 -0400 (EDT) Received: by mail-pf1-f199.google.com with SMTP id i76-v6so5303406pfk.14 for ; Wed, 03 Oct 2018 23:28:18 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id u37-v6si3355453pgl.585.2018.10.03.23.28.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 23:28:17 -0700 (PDT) Date: Thu, 4 Oct 2018 08:28:11 +0200 From: Michal Hocko Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Message-ID: <20181004062811.GC22173@dhcp22.suse.cz> References: <20180928150357.12942-1-david@redhat.com> <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> <20181003135407.GI4714@dhcp22.suse.cz> <9fef1f7d-2d7c-03f1-00e3-5fa657eda019@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fef1f7d-2d7c-03f1-00e3-5fa657eda019@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: David Hildenbrand Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, devel@linuxdriverproject.org, linux-acpi@vger.kernel.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, Tony Luck , Fenghua Yu , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "Rafael J. Wysocki" , Len Brown , Greg Kroah-Hartman , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Boris Ostrovsky , Juergen Gross , =?iso-8859-1?B?Suly9G1l?= Glisse , Andrew Morton , Mike Rapoport , Dan Williams , Stephen Rothwell , "Kirill A. Shutemov" , Nicholas Piggin , Jonathan =?iso-8859-1?Q?Neusch=E4fer?= , Joe Perches , Michael Neuling , Mauricio Faria de Oliveira , Balbir Singh , Rashmica Gupta , Pavel Tatashin , Rob Herring , Philippe Ombredanne , Kate Stewart , "mike.travis@hpe.com" , Joonsoo Kim , Oscar Salvador , Mathieu Malaterre On Wed 03-10-18 19:00:29, David Hildenbrand wrote: [...] > Let me rephrase: You state that user space has to make the decision and > that user should be able to set/reconfigure rules. That is perfectly fine. > > But then we should give user space access to sufficient information to > make a decision. This might be the type of memory as we learned (what > some part of this patch proposes), but maybe later more, e.g. to which > physical device memory belongs (e.g. to hotplug it all movable or all > normal) ... I am pretty sure that user knows he/she wants to use ballooning in HyperV or Xen, or that the memory hotplug should be used as a "RAS" feature to allow add and remove DIMMs for reliability. Why shouldn't we have a package to deploy an appropriate set of udev rules for each of those usecases? I am pretty sure you need some other plumbing to enable them anyway (e.g. RAS would require to have movable_node kernel parameters, ballooning a kernel module etc.). Really, one udev script to rule them all will simply never work. -- Michal Hocko SUSE Labs