Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5707182imm; Wed, 12 Sep 2018 09:52:28 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY7o8+XA3NBDJE6iVxlVqANZDC3krgRRTIYP9zfI/+qK9jCxdowm9F8edYU33pGZ9Fo+QPQ X-Received: by 2002:a63:7f06:: with SMTP id a6-v6mr3337901pgd.296.1536771148856; Wed, 12 Sep 2018 09:52:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536771148; cv=none; d=google.com; s=arc-20160816; b=RtGkKSrZFcscD7k7XkPR17wNGIBvvu8ISRcZdkoS8QN4YlbBvSHMM32KN1hA6DsuUi xXwlox/vfud5fzVnQ+YpMSZ0c2bAJEyxjn0zsELz7+QNQQCvm1dws+Bv2HejAVknY6ZN HafTo45KjKbnZakSCgbKME0Zzqx0w5uXdhlTT4/xhd+iAS3XrT8TMGABLGdpb8Wrjx8H yoQ27dqJngffBZS5PRy0X8zMLv3WVGHG2dR9JVPp/jxdDj6uErDoUuiFswFAtk4yHyhB SMU/LSA9aObZHI6rX7+98MGLVg5Rl7l741XuUt3soFmP6Ie38wqFAlOetCRf5/a3bjC9 wuAA== 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 :references:in-reply-to:mime-version:dkim-signature; bh=DIYxv93rRAzXjcu5CZZeSxm9Bznzoy5ezbvq9mlSvLE=; b=kxt6XOT14Nbx4l2MCloYTtvylSSedcmeYOx+upUFlSL9ihn3QO0rbC2/0ZGSI4sQGq Alvk6droG57zNVCI6QDTniR0jVf2KRMgBBDfPfRXRASfswgzIaGKeLRH6HQujP4++IJx GMqaKcZ9iJpCDS40+/QaB3R6r1pyXmtY74Y7GqRIGaRebAX4NDSOIVZqsNlouoz9EN9B Ld6fBuiClab1421yw79tNB8YwmCf5RDdFtNlSdBw4x/jBJpO0UsSNehH4DgLjES7i7Ux RdxTNjYTNqy8u/B0JJq8TMIx2tLOXwJhh1SO7jFCyRSw9GareIKgzUSaR3wph6+OckdH e3eQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=X31X476t; 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 p83-v6si1413460pfa.180.2018.09.12.09.52.14; Wed, 12 Sep 2018 09:52:28 -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=X31X476t; 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 S1728046AbeILVz6 (ORCPT + 99 others); Wed, 12 Sep 2018 17:55:58 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:39105 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726798AbeILVz6 (ORCPT ); Wed, 12 Sep 2018 17:55:58 -0400 Received: by mail-oi0-f67.google.com with SMTP id c190-v6so5084391oig.6 for ; Wed, 12 Sep 2018 09:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DIYxv93rRAzXjcu5CZZeSxm9Bznzoy5ezbvq9mlSvLE=; b=X31X476ttYUAQ5o+3jegptzO4RAij1oC48x1E8rKa7BVK2TeQNgdS+I3HuCMlxNzWQ XXm4dL8ISc561rJqUhsG0EpVhHyAmtmRK/YzS+711e+4IT4ND6t2E+o0JUFqOV8nU5O2 dEo/6itT8GIPjfgm9KGjCT5GhGFiAZ+ndLvObRZHOMmG63pkKx2qHlFsk9HJ1uLW4Sbs xPIJmn8+8R6kZZNVYxa+V7BPczKG6IRmsvDB06PjORv7jDYI1d5UXmH9vFPASkfTW7H0 r0ISFUgsgPWfAg2uC7usVChkNQQYL7tnrOINvAFQXpfddsDR2iL2oH7Ux6VjWQERu6dk SYmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DIYxv93rRAzXjcu5CZZeSxm9Bznzoy5ezbvq9mlSvLE=; b=ToZn3ivQGYE5ZdnJNURUc1FVN2H3s7k91xFnIgPoWGzNAQUNpZj3860uK2haSwY4rX ypZtOolZ7wTCctkw2tRl77eoFVfLdo1yEHlNb5rLkT/jZyK5bW+3OIKygTsKZlMbpkcV 8T9J4sU9ObeUDmvyjwNOc9JU+7/1tdZ02HPJvMsytb0b4BjCjqAR0pXrfgAoLqKVGnST fAEQL7/i63PmbyyWvmAYatXCFPho5FLNxFUKt8BZMFlw1bpvqCn9XpmiQdWe4UWajK/4 u0eLo5xRmet8tU8vhQK+lzM8cPJrJmSLyfKNN8fY+IgTfuvZ9vhnfiATnTrY7u/dsI+U 1lyQ== X-Gm-Message-State: APzg51DckZT3r6pSXCyyewrCDtpvqFtLbwQgnnHuAUrUqBCsRNP7RL5H 1ZwQ1oUWmvxLkIvQmZEKYP8I++FRDgEUpe1DEQMoYw== X-Received: by 2002:aca:ec0d:: with SMTP id k13-v6mr3073695oih.236.1536771034706; Wed, 12 Sep 2018 09:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8e85:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 09:50:34 -0700 (PDT) In-Reply-To: References: <20180910232615.4068.29155.stgit@localhost.localdomain> <20180910234354.4068.65260.stgit@localhost.localdomain> <7b96298e-9590-befd-0670-ed0c9fcf53d5@microsoft.com> From: Dan Williams Date: Wed, 12 Sep 2018 09:50:34 -0700 Message-ID: Subject: Re: [PATCH 3/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap To: Alexander Duyck Cc: Pavel.Tatashin@microsoft.com, linux-mm , LKML , linux-nvdimm , Michal Hocko , Dave Jiang , Ingo Molnar , Dave Hansen , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrew Morton , Logan Gunthorpe , "Kirill A. Shutemov" 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 Wed, Sep 12, 2018 at 8:48 AM, Alexander Duyck wrote: > On Wed, Sep 12, 2018 at 6:59 AM Pasha Tatashin > wrote: >> >> Hi Alex, > > Hi Pavel, > >> Please re-base on linux-next, memmap_init_zone() has been updated there >> compared to mainline. You might even find a way to unify some parts of >> memmap_init_zone and memmap_init_zone_device as memmap_init_zone() is a >> lot simpler now. > > This patch applied to the linux-next tree with only a little bit of > fuzz. It looks like it is mostly due to some code you had added above > the function as well. I have updated this patch so that it will apply > to both linux and linux-next by just moving the new function to > underneath memmap_init_zone instead of above it. > >> I think __init_single_page() should stay local to page_alloc.c to keep >> the inlining optimization. > > I agree. In addition it will make pulling common init together into > one space easier. I would rather not have us create an opportunity for > things to further diverge by making it available for anybody to use. I'll buy the inline argument for keeping the new routine in page_alloc.c, but I otherwise do not see the divergence danger or "making __init_single_page() available for anybody" given the the declaration is limited in scope to a mm/ local header file.