Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp719202ima; Wed, 24 Oct 2018 08:11:26 -0700 (PDT) X-Google-Smtp-Source: AJdET5db9Xf/mdA4LvijW846bj1H1UT5NyH73IXEqeNAPFPAYlgp06zrwKCFjAbBsCXe45X4HPnp X-Received: by 2002:a17:902:850b:: with SMTP id bj11-v6mr2935632plb.107.1540393886733; Wed, 24 Oct 2018 08:11:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540393886; cv=none; d=google.com; s=arc-20160816; b=NYT8jR5pSh3BiBwWE9G3hLRsmUkpTH5Dn6UngQpXLgPXH5w4Q8JqtpZEtz9wwYaycH ahhFGmwDhd7fbi7voESAJkPGjlEQr8qq+7xunQiNHtiBZs572E+2eSqZZyeKAL6sWVDK EV+g5OIl2BJXR0e4+jT2bXAsdfj8qLhnCtLcOoi+2xMWRLLoN2vcdS/8iauLTaAXh+Gc /iOsGS0S5s9Pv/LyH8HyuvqCKVbePsNOxiDU4CTwY3Pd/jL2JVZZlCQGhgF87OMMT384 jTbzl6p5nyxv5liAkQB5dKQvRp5VhvJA6b5X0GrxHX2HfsASqEfRrIB1dNmrN/ZgVK9L 2Dhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=3LadbfScB1V2g+0XA5KWXtehkpUq0IZTU7HFcGZRelQ=; b=s7/eLS88UbeMUHujVG6e+yfL/HMawLUyY/ZZ5G18yjLJY+6fXKZ78pL7LqQPlmTKPP kcJSMo2GFcr0GHsN6IFpkg7oovLYcvKixet2sbkhNhz6ZQmWiFP2hMDS3IyZP1z115Kx LcnYQHg5CEhPqYTK/cwItklucnBFWbKbEN1xcQrdpI//i7KpfMR5hlZxGSRMXJtsjA0U qCGIYdRYn/VzN2d+Ja4+t+/cbFuNJY6I1d6VpF2cQr5btKuij4mJZ56op0rmRSSA1QTr oTmYfpIbucy8SmS2LvmhBo7nqy3kWwGCv9TdqUEAGw0X+va538xPEnfYZUkoGTNsiUw7 XXjw== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r22-v6si6178062pfr.18.2018.10.24.08.10.47; Wed, 24 Oct 2018 08:11:26 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726851AbeJXXhK (ORCPT + 99 others); Wed, 24 Oct 2018 19:37:10 -0400 Received: from mga06.intel.com ([134.134.136.31]:10898 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726414AbeJXXhK (ORCPT ); Wed, 24 Oct 2018 19:37:10 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 08:08:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,420,1534834800"; d="scan'208";a="102923006" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga002.jf.intel.com with ESMTP; 24 Oct 2018 08:08:41 -0700 Message-ID: <40b17814b2a65531c5059e52a61c8f41b9603904.camel@linux.intel.com> Subject: Re: [mm PATCH v3 4/6] mm: Move hot-plug specific memory init into separate functions and optimize From: Alexander Duyck To: Michal Hocko Cc: linux-mm@kvack.org, akpm@linux-foundation.org, pavel.tatashin@microsoft.com, dave.jiang@intel.com, linux-kernel@vger.kernel.org, willy@infradead.org, davem@davemloft.net, yi.z.zhang@linux.intel.com, khalid.aziz@oracle.com, rppt@linux.vnet.ibm.com, vbabka@suse.cz, sparclinux@vger.kernel.org, dan.j.williams@intel.com, ldufour@linux.vnet.ibm.com, mgorman@techsingularity.net, mingo@kernel.org, kirill.shutemov@linux.intel.com Date: Wed, 24 Oct 2018 08:08:41 -0700 In-Reply-To: <20181024123640.GF18839@dhcp22.suse.cz> References: <20181015202456.2171.88406.stgit@localhost.localdomain> <20181015202716.2171.7284.stgit@localhost.localdomain> <20181017091824.GL18839@dhcp22.suse.cz> <20181024123640.GF18839@dhcp22.suse.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-10-24 at 14:36 +0200, Michal Hocko wrote: > On Wed 17-10-18 08:26:20, Alexander Duyck wrote: > [...] > > With that said I am also wondering if a possible solution to the > > complaints > > you had would be to look at just exporting the __init_pageblock > > function > > later and moving the call to memmap_init_zone_device out to the > > memremap or > > hotplug code when Dan gets the refactoring for HMM and memremap all > > sorted > > out. > > Why cannot we simply provide a constructor for each page by the > caller if there are special requirements? we currently have alt_map > to do struct page allocation but nothing really prevents to make it > more generic and control both allocation and initialization whatever > suits a specific usecase. I really do not want make special cases > here and there. The advantage to the current __init_pageblock function is that we end up constructing everything we are going to write outside of the main loop and then are focused only on init. If we end up having to call a per page constructor that is going to slow things down. For example just that reserved bit setting was adding something like 4 seconds to the init time for the system. By allowing it to be configured as a part of the flags outside of the loop I was able to avoid taking that performance hit. - Alex