Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2017294imm; Thu, 27 Sep 2018 06:14:55 -0700 (PDT) X-Google-Smtp-Source: ACcGV63uD5FZsmXlC2PJxe90zeG1WKz5zhMm4ppLW9ZSKiY0z1nd6cv+dMLYTN2I/dcPLRjWM0NG X-Received: by 2002:a63:844:: with SMTP id 65-v6mr10407163pgi.144.1538054095437; Thu, 27 Sep 2018 06:14:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538054095; cv=none; d=google.com; s=arc-20160816; b=Qz52KlCHrj11irZp3+2AMpe+bOoeOQfZtDT3zCtt8wsL9wAw9ztFOthjrOcSD6w9d/ 3tr80aw7QUxMQQOGvz4rD9x+XYDQrGPfLD6+d5Df6/Qk6aCt6YwQNE03M5SkoNX5KCRV sr5/knHKKwWOcNl8t+B4DBs8h1TouGR0Ui0+S7U2orx/UeD0+IqfA//4VPi2aVOWqQYT IiJdHVeO5IUaeCYJ+HWyKOwA4OvQ4VwHxMiDyyoY85L0EQRkw8F5avlxS/4BZs9n7fTS gRujzKyQzZoPBtUogWYD1rR53NskoA18mnrBh3G9DFp8fTia58leTeNnT06ict4DRBu/ eHEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=pBK5jKB8euSo4hRIq9wnDpZUXV/mbRZk+9fW5vWdM+Q=; b=A3nz5WmAVkYJPN/6gMvtzrOh0YoO/3koe+GJjdQ4D6lwRg+woUddVqRqQrHOw5b60j FeJaNFlp2BKAYiK6/Or0YsmRF33HpltfRsnVmLxhGAShUkKtVJFxviB+eWkI2+N0Poay rqGGSZ7zEPnYrG9micrx1102/g6yj+tlcJ6A+gtX+uYQIpkIteA/pMbtxk84E6GJOV2/ VlqW9Nn35yTjL8Nq8yXKrmGB6gVZjznocVele+2ZLuTTaF9fScUX4CXRZDd20M5kkrJ5 KUjnsdXBLqmNYd6YcQ5lAaq6Rcv3CkKZUTyygKG/PyuGWt3gjB27wIOCrLuEXWxtfpra BXHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13-v6si1903935pgk.127.2018.09.27.06.14.38; Thu, 27 Sep 2018 06:14:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727615AbeI0Tbq (ORCPT + 99 others); Thu, 27 Sep 2018 15:31:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:56010 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727326AbeI0Tbq (ORCPT ); Thu, 27 Sep 2018 15:31:46 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 1C472AD8D; Thu, 27 Sep 2018 13:13:32 +0000 (UTC) Date: Thu, 27 Sep 2018 15:13:29 +0200 From: Michal Hocko To: Oscar Salvador Cc: Alexander Duyck , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, pavel.tatashin@microsoft.com, dave.jiang@intel.com, dave.hansen@intel.com, jglisse@redhat.com, rppt@linux.vnet.ibm.com, dan.j.williams@intel.com, logang@deltatee.com, mingo@kernel.org, kirill.shutemov@linux.intel.com Subject: Re: [PATCH v5 4/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Message-ID: <20180927131329.GI6278@dhcp22.suse.cz> References: <20180925200551.3576.18755.stgit@localhost.localdomain> <20180925202053.3576.66039.stgit@localhost.localdomain> <20180926075540.GD6278@dhcp22.suse.cz> <6f87a5d7-05e2-00f4-8568-bb3521869cea@linux.intel.com> <20180927110926.GE6278@dhcp22.suse.cz> <20180927122537.GA20378@techadventures.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180927122537.GA20378@techadventures.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 27-09-18 14:25:37, Oscar Salvador wrote: > On Thu, Sep 27, 2018 at 01:09:26PM +0200, Michal Hocko wrote: > > > So there were a few things I wasn't sure we could pull outside of the > > > hotplug lock. One specific example is the bits related to resizing the pgdat > > > and zone. I wanted to avoid pulling those bits outside of the hotplug lock. > > > > Why would that be a problem. There are dedicated locks for resizing. > > True is that move_pfn_range_to_zone() manages the locks for pgdat/zone resizing, > but it also takes care of calling init_currently_empty_zone() in case the zone is empty. > Could not that be a problem if we take move_pfn_range_to_zone() out of the lock? I would have to double check but is the hotplug lock really serializing access to the state initialized by init_currently_empty_zone? E.g. zone_start_pfn is a nice example of a state that is used outside of the lock. zone's free lists are similar. So do we really need the hoptlug lock? And more broadly, what does the hotplug lock is supposed to serialize in general. A proper documentation would surely help to answer these questions. There is way too much of "do not touch this code and just make my particular hack" mindset which made the whole memory hotplug a giant pile of mess. We really should start with some proper engineering here finally. -- Michal Hocko SUSE Labs