Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752105AbdCMJWq (ORCPT ); Mon, 13 Mar 2017 05:22:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:41957 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752665AbdCMJVu (ORCPT ); Mon, 13 Mar 2017 05:21:50 -0400 Date: Mon, 13 Mar 2017 10:21:45 +0100 From: Michal Hocko To: Reza Arbab Cc: Igor Mammedov , Heiko Carstens , Vitaly Kuznetsov , linux-mm@kvack.org, Andrew Morton , Greg KH , "K. Y. Srinivasan" , David Rientjes , Daniel Kiper , linux-api@vger.kernel.org, LKML , linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, qiuxishi@huawei.com, toshi.kani@hpe.com, xieyisheng1@huawei.com, slaoub@gmail.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, Zhang Zhen , Yasuaki Ishimatsu , Tang Chen Subject: Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks) Message-ID: <20170313092145.GG31518@dhcp22.suse.cz> References: <20170302142816.GK1404@dhcp22.suse.cz> <20170302180315.78975d4b@nial.brq.redhat.com> <20170303082723.GB31499@dhcp22.suse.cz> <20170303183422.6358ee8f@nial.brq.redhat.com> <20170306145417.GG27953@dhcp22.suse.cz> <20170307134004.58343e14@nial.brq.redhat.com> <20170309125400.GI11592@dhcp22.suse.cz> <20170310135807.GI3753@dhcp22.suse.cz> <20170310155333.GN3753@dhcp22.suse.cz> <20170310190037.fifahjd47joim6zy@arbab-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170310190037.fifahjd47joim6zy@arbab-laptop> 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: 1419 Lines: 33 On Fri 10-03-17 13:00:37, Reza Arbab wrote: > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > >OK, so while I was playing with this setup some more I probably got why > >this is done this way. All new memblocks are added to the zone Normal > >where they are accounted as spanned but not present. > > It's not always zone Normal. See zone_for_memory(). This leads to a > workaround for having to do online_movable in descending block order. > Instead of this: > > 1. probe block 34, probe block 33, probe block 32, ... > 2. online_movable 34, online_movable 33, online_movable 32, ... > > you can online_movable the first block before adding the rest: I do I enforce that behavior when the probe happens automagically? > 1. probe block 32, online_movable 32 > 2. probe block 33, probe block 34, ... > - zone_for_memory() will cause these to start Movable > 3. online 33, online 34, ... > - they're already in Movable, so online_movable is equivalentr > > I agree with your general sentiment that this stuff is very nonintuitive. My criterion for nonintuitive is probably different because I would call this _completely_unusable_. Sorry for being so loud about this but the more I look into this area the more WTF code I see. This has seen close to zero review and seems to be building up more single usecase code on top of previous. We need to change this, seriously! -- Michal Hocko SUSE Labs