From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 2B3C46B0313 for ; Wed, 26 Jul 2017 08:30:47 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id p17so7572831wmd.5 for ; Wed, 26 Jul 2017 05:30:47 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id k32si272253wrc.311.2017.07.26.05.30.45 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 26 Jul 2017 05:30:46 -0700 (PDT) Date: Wed, 26 Jul 2017 14:30:41 +0200 From: Michal Hocko Subject: Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap Message-ID: <20170726123040.GO2981@dhcp22.suse.cz> References: <20170726083333.17754-1-mhocko@kernel.org> <20170726083333.17754-4-mhocko@kernel.org> <20170726114539.GG3218@osiris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170726114539.GG3218@osiris> Sender: owner-linux-mm@kvack.org List-ID: To: Heiko Carstens Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Vlastimil Babka , Andrea Arcangeli , Jerome Glisse , Reza Arbab , Yasuaki Ishimatsu , qiuxishi@huawei.com, Kani Toshimitsu , slaoub@gmail.com, Joonsoo Kim , Andi Kleen , Daniel Kiper , Igor Mammedov , Vitaly Kuznetsov , LKML , Benjamin Herrenschmidt , Dan Williams , "H. Peter Anvin" , Ingo Molnar , Michael Ellerman , Paul Mackerras , Thomas Gleixner , Gerald Schaefer On Wed 26-07-17 13:45:39, Heiko Carstens wrote: [...] > In general I do like your idea, however if I understand your patches > correctly we might have an ordering problem on s390: it is not possible to > access hot-added memory on s390 before it is online (MEM_GOING_ONLINE > succeeded). Could you point me to the code please? I cannot seem to find the notifier which implements that. > On MEM_GOING_ONLINE we ask the hypervisor to back the potential available > hot-added memory region with physical pages. Accessing those ranges before > that will result in an exception. Can we make the range which backs the memmap range available? E.g from s390 specific __vmemmap_populate path? > However with your approach the memory is still allocated when add_memory() > is being called, correct? That wouldn't be a change to the current > behaviour; except for the ordering problem outlined above. Could you be more specific please? I do not change when the memmap is allocated. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org