From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Kuznetsov Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Date: Wed, 03 Oct 2018 15:38:04 +0200 Message-ID: <8736tndubn.fsf@vitty.brq.redhat.com> References: <20180928150357.12942-1-david@redhat.com> <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: David Hildenbrand , Michal Hocko 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, Paul Mackerras , "H. Peter Anvin" , Stephen Rothwell , Rashmica Gupta , Dan Williams , 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, Len Brown , Pavel List-Id: linux-acpi@vger.kernel.org David Hildenbrand writes: > On 02/10/2018 15:47, Michal Hocko wrote: ... >> >> Why do you need a generic hotplug rule in the first place? Why don't you >> simply provide different set of rules for different usecases? Let users >> decide which usecase they prefer rather than try to be clever which >> almost always hits weird corner cases. >> > > Memory hotplug has to work as reliable as we can out of the box. Letting > the user make simple decisions like "oh, I am on hyper-V, I want to > online memory to the normal zone" does not feel right. But yes, we > should definitely allow to make modifications. Last time I was thinking about the imperfectness of the auto-online solution we have and any other solution we're able to suggest an idea came to my mind - what if we add an eBPF attach point to the auto-onlining mechanism effecively offloading decision-making to userspace. We'll of couse need to provide all required data (e.g. how memory blocks are aligned with physical DIMMs as it makes no sense to online part of DIMM as normal and the rest as movable as it's going to be impossible to unplug such DIMM anyways). -- Vitaly 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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 C693DC00449 for ; Wed, 3 Oct 2018 13:42:55 +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 3F1F120684 for ; Wed, 3 Oct 2018 13:42:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3F1F120684 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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 42QHJs0CjGzDr43 for ; Wed, 3 Oct 2018 23:42:53 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=redhat.com (client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=vkuznets@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42QHCk56pfzDr8q for ; Wed, 3 Oct 2018 23:38:23 +1000 (AEST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BBCD6300287B; Wed, 3 Oct 2018 13:38:19 +0000 (UTC) Received: from vitty.brq.redhat.com.redhat.com (unknown [10.43.2.58]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C648027BC4; Wed, 3 Oct 2018 13:38:06 +0000 (UTC) From: Vitaly Kuznetsov To: David Hildenbrand , Michal Hocko Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types In-Reply-To: <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> References: <20180928150357.12942-1-david@redhat.com> <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> Date: Wed, 03 Oct 2018 15:38:04 +0200 Message-ID: <8736tndubn.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Wed, 03 Oct 2018 13:38:21 +0000 (UTC) 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, 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 , Jonathan =?utf-8?Q?Neusch=C3=A4fer?= , Nicholas Piggin , Martin Schwidefsky , =?utf-8?B?SsOpcsO0?= =?utf-8?B?bWU=?= Glisse , Mike Rapoport , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , 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 , Joe Perches , devel@linuxdriverproject.org, Joonsoo Kim , linuxppc-dev@lists.ozlabs.org, "Kirill A. Shutemov" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" David Hildenbrand writes: > On 02/10/2018 15:47, Michal Hocko wrote: ... >> >> Why do you need a generic hotplug rule in the first place? Why don't you >> simply provide different set of rules for different usecases? Let users >> decide which usecase they prefer rather than try to be clever which >> almost always hits weird corner cases. >> > > Memory hotplug has to work as reliable as we can out of the box. Letting > the user make simple decisions like "oh, I am on hyper-V, I want to > online memory to the normal zone" does not feel right. But yes, we > should definitely allow to make modifications. Last time I was thinking about the imperfectness of the auto-online solution we have and any other solution we're able to suggest an idea came to my mind - what if we add an eBPF attach point to the auto-onlining mechanism effecively offloading decision-making to userspace. We'll of couse need to provide all required data (e.g. how memory blocks are aligned with physical DIMMs as it makes no sense to online part of DIMM as normal and the rest as movable as it's going to be impossible to unplug such DIMM anyways). -- Vitaly From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by kanga.kvack.org (Postfix) with ESMTP id 2B9456B0271 for ; Wed, 3 Oct 2018 09:38:23 -0400 (EDT) Received: by mail-qt1-f199.google.com with SMTP id d18-v6so5049077qtj.20 for ; Wed, 03 Oct 2018 06:38:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id p9-v6si924977qvd.85.2018.10.03.06.38.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 06:38:22 -0700 (PDT) From: Vitaly Kuznetsov Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types In-Reply-To: <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> References: <20180928150357.12942-1-david@redhat.com> <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> Date: Wed, 03 Oct 2018 15:38:04 +0200 Message-ID: <8736tndubn.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: David Hildenbrand , Michal Hocko 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 , Len Brown , Fenghua Yu , Stephen Rothwell , "mike.travis@hpe.com" , Haiyang Zhang , Dan Williams , Jonathan =?utf-8?Q?Neusch=C3=A4fer?= , Nicholas Piggin , Joe Perches , =?utf-8?B?SsOpcsO0?= =?utf-8?B?bWU=?= 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" David Hildenbrand writes: > On 02/10/2018 15:47, Michal Hocko wrote: ... >> >> Why do you need a generic hotplug rule in the first place? Why don't you >> simply provide different set of rules for different usecases? Let users >> decide which usecase they prefer rather than try to be clever which >> almost always hits weird corner cases. >> > > Memory hotplug has to work as reliable as we can out of the box. Letting > the user make simple decisions like "oh, I am on hyper-V, I want to > online memory to the normal zone" does not feel right. But yes, we > should definitely allow to make modifications. Last time I was thinking about the imperfectness of the auto-online solution we have and any other solution we're able to suggest an idea came to my mind - what if we add an eBPF attach point to the auto-onlining mechanism effecively offloading decision-making to userspace. We'll of couse need to provide all required data (e.g. how memory blocks are aligned with physical DIMMs as it makes no sense to online part of DIMM as normal and the rest as movable as it's going to be impossible to unplug such DIMM anyways). -- Vitaly