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 16:34:03 +0200 Message-ID: <87tvm3cd5w.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> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49456818-238e-2d95-9df6-d1934e9c8b53@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Dave Hansen , Michal Hocko Cc: Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Benjamin Herrenschmidt , Balbir Singh , 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 , David Hildenbrand , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Len Brown Pavel Tatashin

List-Id: linux-acpi@vger.kernel.org Dave Hansen writes: > On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote: >> It is more than just memmaps (e.g. forking udev process doing memory >> onlining also needs memory) but yes, the main idea is to make the >> onlining synchronous with hotplug. > > That's a good theoretical concern. > > But, is it a problem we need to solve in practice? Yes, unfortunately. It was previously discovered that when we try to hotplug tons of memory to a low memory system (this is a common scenario with VMs) we end up with OOM because for all new memory blocks we need to allocate page tables, struct pages, ... and we need memory to do that. The userspace program doing memory onlining also needs memory to run and in case it prefers to fork to handle hundreds of notfifications ... well, it may get OOMkilled before it manages to online anything. Allocating all kernel objects from the newly hotplugged blocks would definitely help to manage the situation but as I said this won't solve the 'forking udev' problem completely (it will likely remain in 'extreme' cases only. We can probably work around it by onlining with a dedicated process which doesn't do memory allocation). -- 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,URIBL_BLOCKED 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 93522C00449 for ; Wed, 3 Oct 2018 14:36: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 1AE492089F for ; Wed, 3 Oct 2018 14:36:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1AE492089F 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 42QJW20JVyzF397 for ; Thu, 4 Oct 2018 00:36:46 +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 42QJSJ34VSzF386 for ; Thu, 4 Oct 2018 00:34:23 +1000 (AEST) Received: from smtp.corp.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 857A73082128; Wed, 3 Oct 2018 14:34:20 +0000 (UTC) Received: from vitty.brq.redhat.com.redhat.com (unknown [10.43.2.58]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EFFFC30912F5; Wed, 3 Oct 2018 14:34:05 +0000 (UTC) From: Vitaly Kuznetsov To: Dave Hansen , Michal Hocko Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types In-Reply-To: <49456818-238e-2d95-9df6-d1934e9c8b53@linux.intel.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> <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> Date: Wed, 03 Oct 2018 16:34:03 +0200 Message-ID: <87tvm3cd5w.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Wed, 03 Oct 2018 14:34:22 +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 , 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 , David Hildenbrand , 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" Dave Hansen writes: > On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote: >> It is more than just memmaps (e.g. forking udev process doing memory >> onlining also needs memory) but yes, the main idea is to make the >> onlining synchronous with hotplug. > > That's a good theoretical concern. > > But, is it a problem we need to solve in practice? Yes, unfortunately. It was previously discovered that when we try to hotplug tons of memory to a low memory system (this is a common scenario with VMs) we end up with OOM because for all new memory blocks we need to allocate page tables, struct pages, ... and we need memory to do that. The userspace program doing memory onlining also needs memory to run and in case it prefers to fork to handle hundreds of notfifications ... well, it may get OOMkilled before it manages to online anything. Allocating all kernel objects from the newly hotplugged blocks would definitely help to manage the situation but as I said this won't solve the 'forking udev' problem completely (it will likely remain in 'extreme' cases only. We can probably work around it by onlining with a dedicated process which doesn't do memory allocation). -- Vitaly From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by kanga.kvack.org (Postfix) with ESMTP id A82446B0008 for ; Wed, 3 Oct 2018 10:34:23 -0400 (EDT) Received: by mail-qk1-f199.google.com with SMTP id v14-v6so5136376qkg.8 for ; Wed, 03 Oct 2018 07:34:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id i11-v6si1001029qvb.29.2018.10.03.07.34.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 07:34:22 -0700 (PDT) From: Vitaly Kuznetsov Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types In-Reply-To: <49456818-238e-2d95-9df6-d1934e9c8b53@linux.intel.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> <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> Date: Wed, 03 Oct 2018 16:34:03 +0200 Message-ID: <87tvm3cd5w.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: Dave Hansen , Michal Hocko Cc: David Hildenbrand , Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Benjamin Herrenschmidt , Balbir Singh , 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" Dave Hansen writes: > On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote: >> It is more than just memmaps (e.g. forking udev process doing memory >> onlining also needs memory) but yes, the main idea is to make the >> onlining synchronous with hotplug. > > That's a good theoretical concern. > > But, is it a problem we need to solve in practice? Yes, unfortunately. It was previously discovered that when we try to hotplug tons of memory to a low memory system (this is a common scenario with VMs) we end up with OOM because for all new memory blocks we need to allocate page tables, struct pages, ... and we need memory to do that. The userspace program doing memory onlining also needs memory to run and in case it prefers to fork to handle hundreds of notfifications ... well, it may get OOMkilled before it manages to online anything. Allocating all kernel objects from the newly hotplugged blocks would definitely help to manage the situation but as I said this won't solve the 'forking udev' problem completely (it will likely remain in 'extreme' cases only. We can probably work around it by onlining with a dedicated process which doesn't do memory allocation). -- Vitaly