Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757641AbdCUOKY (ORCPT ); Tue, 21 Mar 2017 10:10:24 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33244 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756654AbdCUOKU (ORCPT ); Tue, 21 Mar 2017 10:10:20 -0400 MIME-Version: 1.0 In-Reply-To: <20170317132036.GI26298@dhcp22.suse.cz> References: <20170315091347.GA32626@dhcp22.suse.cz> <20170317132036.GI26298@dhcp22.suse.cz> From: Dan Williams Date: Tue, 21 Mar 2017 07:09:15 -0700 Message-ID: Subject: Re: [RFC PATCH] rework memory hotplug onlining To: Michal Hocko Cc: linux-mm , Mel Gorman , qiuxishi@huawei.com, Toshi Kani , xieyisheng1@huawei.com, slaoub@gmail.com, Joonsoo Kim , Zhang Zhen , Reza Arbab , Yasuaki Ishimatsu , Tang Chen , Vlastimil Babka , Andrea Arcangeli , LKML , Andrew Morton , David Rientjes , Daniel Kiper , Igor Mammedov , Vitaly Kuznetsov , Andi Kleen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1412 Lines: 26 On Fri, Mar 17, 2017 at 6:20 AM, Michal Hocko wrote: > On Wed 15-03-17 10:13:47, Michal Hocko wrote: > [...] >> It seems that all this is just started by the semantic introduced by >> 9d99aaa31f59 ("[PATCH] x86_64: Support memory hotadd without sparsemem") >> quite some time ago. When the movable onlinining has been introduced it >> just built on top of this. It seems that the requirement to have >> freshly probed memory associated with the zone normal is no longer >> necessary. HOTPLUG depends on CONFIG_SPARSEMEM these days. >> >> The following blob [2] simply removes all the zone specific operations >> from __add_pages (aka arch_add_memory) path. Instead we do page->zone >> association from move_pfn_range which is called from online_pages. The >> criterion for movable/normal zone association is really simple now. We >> just have to guarantee that zone Normal is always lower than zone >> Movable. It would be actually sufficient to guarantee they do not >> overlap and that is indeed trivial to implement now. I didn't do that >> yet for simplicity of this change though. > > Does anybody have any comments on this? Any issues I've overlooked > (except for the one pointed by Toshi Kani which is already fixed in my > local branch)? It disables the ZONE_DEVICE use case, but like we chatted about at LSF I'll take a look at having devm_memremap_pages() call move_pfn_range().