From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752151AbdCSQxw (ORCPT ); Sun, 19 Mar 2017 12:53:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:32942 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751977AbdCSQxt (ORCPT ); Sun, 19 Mar 2017 12:53:49 -0400 Date: Sun, 19 Mar 2017 12:35:31 -0400 From: Michal Hocko To: Dan Williams Cc: Andrew Morton , Toshi Kani , "linux-nvdimm@lists.01.org" , Logan Gunthorpe , "linux-kernel@vger.kernel.org" , Stephen Bates , Linux MM , Nicolai Stange , Alexander Potapenko , Dmitry Vyukov , Johannes Weiner , Andrey Ryabinin , Mel Gorman , Vlastimil Babka Subject: Re: [PATCH v4 00/13] mm: sub-section memory hotplug support Message-ID: <20170319163531.GA25835@dhcp22.suse.cz> References: <148964440651.19438.2288075389153762985.stgit@dwillia2-desk3.amr.corp.intel.com> <20170316174805.GB13654@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Thu 16-03-17 12:04:48, Dan Williams wrote: > On Thu, Mar 16, 2017 at 10:48 AM, Michal Hocko wrote: > > Hi, > > I didn't get to look through the patch series yet and I might not be > > able before LSF/MM. How urgent is this? I am primarily asking because > > the memory hotplug is really convoluted right now and putting more on > > top doesn't really sound like the thing we really want. I have tried to > > simplify the code [1] already but this is an early stage work so I do > > not want to impose any burden on you. So I am wondering whether this > > is something that needs to be merged very soon or it can wait for the > > rework and hopefully end up being much simpler in the end as well. > > > > What do you think? > > In general, I think it's better to add new features after > reworks/cleanup, but it's not clear to me (yet) that the problem you > are trying to solve makes this sub-section enabling for ZONE_DEVICE > any simpler. > > > [1] http://lkml.kernel.org/r/20170315091347.GA32626@dhcp22.suse.cz > > ZONE_DEVICE pages are never "online". The patch says "Instead we do > page->zone association from move_pfn_range which is called from > online_pages." which means the new scheme currently doesn't comprehend > the sprinkled ZONE_DEVICE hacks in the memory hotplug code. I hope we can get rid of those... > However, that said, I might take a look at whether the hacks belong in > the auto-online code so that we can share the delayed zone > initialization, but still skip marking the memory online per the > expectations of ZONE_DEVICE. I think this should be trivial. AFAIU it should be sufficient to split my move_pfn_range into online_pfn_range which would do the MMOP_ONLINE* handling and the real move_pfn_range which would do the zone specific association. Your devm_memremap_pages would then call this move_pfn_range after arch_add_memory. Or am I overlooking something? I would still have to addapt your changes to remove hardcoded section aligned expectations but that shouldn't be a big problem I guess. I still haven't looked into those deeply to fully understand them. > I expect it would be confusing to have > memblock devices in sysfs for ranges that can't be marked online? Well, if their only valid_zone would be ZONE_DEVICE then I believe it shouldn't be confusing much. -- Michal Hocko SUSE Labs