Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751287AbdCQNd6 (ORCPT ); Fri, 17 Mar 2017 09:33:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:59393 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751242AbdCQNdm (ORCPT ); Fri, 17 Mar 2017 09:33:42 -0400 Date: Fri, 17 Mar 2017 14:20:36 +0100 From: Michal Hocko To: linux-mm@kvack.org Cc: Mel Gorman , qiuxishi@huawei.com, toshi.kani@hpe.com, xieyisheng1@huawei.com, slaoub@gmail.com, iamjoonsoo.kim@lge.com, 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 Subject: Re: [RFC PATCH] rework memory hotplug onlining Message-ID: <20170317132036.GI26298@dhcp22.suse.cz> References: <20170315091347.GA32626@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170315091347.GA32626@dhcp22.suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1197 Lines: 24 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)? -- Michal Hocko SUSE Labs