Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4897716imd; Tue, 30 Oct 2018 08:59:44 -0700 (PDT) X-Google-Smtp-Source: AJdET5fivKi64A0mLtBsChLxvsiIDk4MRvIl4XAZUtZqLHmCWKjp2txuQCTHvoD0eTNPwjGVmvZS X-Received: by 2002:a17:902:bb88:: with SMTP id m8-v6mr18802499pls.120.1540915184682; Tue, 30 Oct 2018 08:59:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540915184; cv=none; d=google.com; s=arc-20160816; b=riDVBRu+ARshsKv6OPBbAAzHBrp/mLvCWPbS4wyCZLXMhU1GK/Xd0ZFjwroaIE9gxW FX9h9ISOY1rtIqkGFbGTAu9m447RORY2rBPiNC9Vnn6ekGKh2IPyIVgr0JPWE7uESjIO lkMiiP9+fy0tallH4Y48dX/oJBmMX3z1MfaHXyFrp/8O4ClWObH1HatE2ZRvCA5sFoc3 Zz25EPW1V+C76R7UaJZW0Evr+nvQOCzHFvQtnsOJvzLPGJU9m7u3o00zUkhdqCVQizPH CwzdHPl0k91i+JnVxOH2bNiI1pujsAunACSI1uLbgCZDZ1dGOjT4ATXU62UjpI67+fdB 3Cjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=cBTw3wYT8YeicD7CM/nix+JIKpDpzrZ7yXAwZhKq6HM=; b=gewyi7HdeTAGPlKIGE09VhBIHi959xmwQvNjiqz2JZbTWWd6g/UhrabwxU0hwrvK6F N8ybbTCYz5KaPbMKSTG4cr5oXmrWjFuns3BTGGxTDcrfTq/98haMRwuhAxLPjNgehgtL 93hoAPa67qGM1n/Q5Jc3emExKlbPL/iP1Fcqjz0XSkhWo6g9UeuZYYfYg6KSaWOuysrK RVr7CUMKJ58hyrCmbFAGt12tbrMHgJ1OBGa7m9GKeeiCnSRtyOiM3IhDLZ3f5NNYIibn vKk4oCoelzB3YwyUDUNQQb5+1oolOUCSsxkJuSWnyW9IAg3tpITejNlbHUPtbr5MxjGf fsGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=i2gDO7MX; 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z33-v6si25190795plb.436.2018.10.30.08.59.28; Tue, 30 Oct 2018 08:59:44 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=i2gDO7MX; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727429AbeJaAwO (ORCPT + 99 others); Tue, 30 Oct 2018 20:52:14 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:38525 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726364AbeJaAwN (ORCPT ); Tue, 30 Oct 2018 20:52:13 -0400 Received: by mail-ot1-f65.google.com with SMTP id f24so5840220otl.5 for ; Tue, 30 Oct 2018 08:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cBTw3wYT8YeicD7CM/nix+JIKpDpzrZ7yXAwZhKq6HM=; b=i2gDO7MXe467P88dNA9Oku1CAnmWAnZSKDJbbJao7681sN4BC6da6bHML3Dah1y4vD m2UdXqrHBSlITQn4vUCXsqwEy8m+RXJYWmrjMORSeAKp49WGnE4UKMHVfbCqumdYz8v8 4JRA51wUGifc6B/hebGp5aFjY5JBYIwBU6S07QYbqi4gY/dL7GY4gDfbTxHFFLbJTKjI iqHffvjUs6t5GZCio3/dvvvWr8LZsH5WuKYjNrOpCW+2RD76hoIH9H4e87hv/TWeWPld zkqqurw2DXEimOnUdlUE+ei9xMMxfg/xB1ms9cU1KwcEFBoj5DMwi9+adzCzZ2UnvGFB 8lrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cBTw3wYT8YeicD7CM/nix+JIKpDpzrZ7yXAwZhKq6HM=; b=qGOIf1Rt+vu/eE7h7cPF5NFpfUUUQ2ajiFcgZgmsiOreJOVS8QSq20qLewVx3k9ST4 UICvENMR/qJkDh+BTSLWdaO+PZEYD+lxvq60uPcHGegB81wQE3o6NCYq6jIjvFuS5QaA cIdlCbhgj0L2uwnxPI3GQbzI1CDSL2THIFmzjjTtQli/R/wfLGVvrzRYbxzKMRCtGEiq 1HijW2rqiFNwIqw8YSLgrdFjqtPQJR3AVQwqk8phyFbeNQ6AT9B47SWeCDm/zrxYapYi eMmHWxSiSy9Vf2yELS3cIatG1ylYs6wCFBo+CkupTkOsvmrxeYFN3aaWEtPtiMg+P0cZ 8Q6w== X-Gm-Message-State: AGRZ1gLGPi0hyDh2f4pPKehRAF55Iplh/L1j+l6+0qAIZzGtiAVGQNrB kolbDEhPmreuL3Yv+ImvxMgBOOSPkdAQsSCNkD0Z2A== X-Received: by 2002:a9d:2ff8:: with SMTP id b53mr6568960otd.229.1540915090793; Tue, 30 Oct 2018 08:58:10 -0700 (PDT) MIME-Version: 1.0 References: <20181029141210.GJ32673@dhcp22.suse.cz> <84f09883c16608ddd2ba88103f43ec6a1c649e97.camel@linux.intel.com> <20181029163528.GL32673@dhcp22.suse.cz> <18dfc5a0db11650ff31433311da32c95e19944d9.camel@linux.intel.com> <20181029172415.GM32673@dhcp22.suse.cz> <8e7a4311a240b241822945c0bb4095c9ffe5a14d.camel@linux.intel.com> <20181029181827.GO32673@dhcp22.suse.cz> <3281f3044fa231bbc1b02d5c5efca3502a0d05a8.camel@linux.intel.com> <20181030062915.GT32673@dhcp22.suse.cz> <20181030081757.GX32673@dhcp22.suse.cz> In-Reply-To: <20181030081757.GX32673@dhcp22.suse.cz> From: Dan Williams Date: Tue, 30 Oct 2018 08:57:58 -0700 Message-ID: Subject: Re: [PATCH v5 4/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap To: Michal Hocko Cc: alexander.h.duyck@linux.intel.com, Linux MM , Andrew Morton , Linux Kernel Mailing List , linux-nvdimm , Pasha Tatashin , Dave Hansen , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , rppt@linux.vnet.ibm.com, Ingo Molnar , "Kirill A. Shutemov" , Zhang Yi , osalvador@techadventures.net Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 30, 2018 at 1:18 AM Michal Hocko wrote: > > On Mon 29-10-18 23:55:12, Dan Williams wrote: > > On Mon, Oct 29, 2018 at 11:29 PM Michal Hocko wrote: [..] > > That testing identified this initialization performance problem and > > thankfully got it addressed in time for the current merge window. > > And I still cannot see a word about that in changelogs. True, I would have preferred that commit 966cf44f637e "mm: defer ZONE_DEVICE page initialization to the point where we init pgmap" include some notes about the scaling advantages afforded by not serializing memmap_init_zone() work. I think this information got distributed across several patch series because removing the lock was not sufficient by itself, Alex went further to also rework the physical socket affinity of the nvdimm sub-system's async initialization threads. As the code gets refactored further it's a chance to add commentary on the scaling expectations of the design.