From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by kanga.kvack.org (Postfix) with ESMTP id DF2456B0003 for ; Mon, 1 Oct 2018 04:40:45 -0400 (EDT) Received: by mail-ed1-f69.google.com with SMTP id x10-v6so1502426edx.9 for ; Mon, 01 Oct 2018 01:40:45 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id u21-v6si8658167eda.251.2018.10.01.01.40.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 01:40:44 -0700 (PDT) Date: Mon, 1 Oct 2018 10:40:38 +0200 From: Michal Hocko Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Message-ID: <20181001084038.GD18290@dhcp22.suse.cz> References: <20180928150357.12942-1-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180928150357.12942-1-david@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 Fri 28-09-18 17:03:57, David Hildenbrand wrote: [...] I haven't read the patch itself but I just wanted to note one thing about this part > For paravirtualized devices it is relevant that memory is onlined as > quickly as possible after adding - and that it is added to the NORMAL > zone. Otherwise, it could happen that too much memory in a row is added > (but not onlined), resulting in out-of-memory conditions due to the > additional memory for "struct pages" and friends. MOVABLE zone as well > as delays might be very problematic and lead to crashes (e.g. zone > imbalance). I have proposed (but haven't finished this due to other stuff) a solution for this. Newly added memory can host memmaps itself and then you do not have the problem in the first place. For vmemmap it would have an advantage that you do not really have to beg for 2MB pages to back the whole section but you would get it for free because the initial part of the section is by definition properly aligned and unused. I yet have to think about the whole proposal but I am missing the most important part. _Who_ is going to use the new exported information and for what purpose. You said that distributions have hard time to distinguish different types of onlinining policies but isn't this something that is inherently usecase specific? -- Michal Hocko SUSE Labs