From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 22ED12194D3B3 for ; Fri, 14 Jun 2019 10:14:18 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id i8so3306673oth.10 for ; Fri, 14 Jun 2019 10:14:18 -0700 (PDT) MIME-Version: 1.0 References: <1560366952-10660-1-git-send-email-cai@lca.pw> <1560376072.5154.6.camel@lca.pw> <87lfy4ilvj.fsf@linux.ibm.com> <20190614153535.GA9900@linux> <24fcb721-5d50-2c34-f44b-69281c8dd760@linux.ibm.com> <16108dac-a4ca-aa87-e3b0-a79aebdcfafd@linux.ibm.com> In-Reply-To: From: Dan Williams Date: Fri, 14 Jun 2019 10:14:06 -0700 Message-ID: Subject: Re: [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page() List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Jeff Moyer Cc: linux-nvdimm , "Aneesh Kumar K.V" , Linux Kernel Mailing List , Linux MM , Qian Cai , Andrew Morton , Oscar Salvador List-ID: On Fri, Jun 14, 2019 at 10:09 AM Jeff Moyer wrote: > > "Aneesh Kumar K.V" writes: > > > On 6/14/19 10:06 PM, Dan Williams wrote: > >> On Fri, Jun 14, 2019 at 9:26 AM Aneesh Kumar K.V > >> wrote: > > > >>> Why not let the arch > >>> arch decide the SUBSECTION_SHIFT and default to one subsection per > >>> section if arch is not enabled to work with subsection. > >> > >> Because that keeps the implementation from ever reaching a point where > >> a namespace might be able to be moved from one arch to another. If we > >> can squash these arch differences then we can have a common tool to > >> initialize namespaces outside of the kernel. The one wrinkle is > >> device-dax that wants to enforce the mapping size, > > > > The fsdax have a much bigger issue right? The file system block size > > is the same as PAGE_SIZE and we can't make it portable across archs > > that support different PAGE_SIZE? > > File system blocks are not tied to page size. They can't be *bigger* > than the page size currently, but they can be smaller. > > Still, I don't see that as an arugment against trying to make the > namespaces work across architectures. Consider a user who only has > sector mode namespaces. We'd like that to work if at all possible. Even with fsdax namespaces I don't see the concern. Yes, DAX might be disabled if the filesystem on the namespace has a block size that is smaller than the current system PAGE_SIZE, but the filesystem will still work. I.e. it's fine to put a 512 byte block size filesystem on a system that has a 4K PAGE_SIZE, you only lose DAX operations, not your data access. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2D0CC31E4B for ; Fri, 14 Jun 2019 17:14:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C887D2183E for ; Fri, 14 Jun 2019 17:14:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="sTwfKZMS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726030AbfFNROT (ORCPT ); Fri, 14 Jun 2019 13:14:19 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:34461 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725802AbfFNROS (ORCPT ); Fri, 14 Jun 2019 13:14:18 -0400 Received: by mail-ot1-f67.google.com with SMTP id n5so3364588otk.1 for ; Fri, 14 Jun 2019 10:14:18 -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=1DOR0lfku3yUBhnRNWEqeIw9f7cV+CNTtUVXtGntF+g=; b=sTwfKZMStgwHohmnokMWPy+VfqEaV8lW2lueb7v8fb896+Vc0aKVzpBH0A2lEJlw6q oALCiHx77zWRNARo52nz8z+FNUxgUwVgBG+v1ofG044GSZOat+JTG9E2WNwyxxib8AG2 gpjqossClsMvuhpes7lVdiSsvyVheT+RRZNuZS9QKm7gxXA0LXlU62z/ZeDVSIkaSKLG q2xdj1lK+22SHsQoDVfk25zVhm3/u/GXGDlHpOQpCSDX6j/uZMH4LMgtT9/w9S6/Uurk O8qQF4zoQsEqPbLE2I2goSlCiHkrB1+UDrJXIaIzjBrMd5fRfGm+SSdXADa62AeNqAyv 0hiQ== 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=1DOR0lfku3yUBhnRNWEqeIw9f7cV+CNTtUVXtGntF+g=; b=bEcuKN49m6UdqvwlYrfgYNEftLbWF/dJCmRymzxOvVRNLGDc2k7mVtjAwRZ7XqGEWF uOe5mnRx0rQqPgRuWkpF11e3MBzpjWXrvVu3ITvKjeocF4hHH2AgM9/9yN/dvTfXlw74 pCsSfnUBqqP6aYVrQHzPjiQzWUkhcixZcHjWhpXW/eHwb+qBCtNvfTYMl2tt77tbX8pw SVglejE8D9wvLO+J5F8SYJtMgL+YYdjpGn8zIkc72lhDl0xiFu6DRpy8jMTOU1AEsTnD 6wP2cVjM5a7YcBfz3Rq0e7I/3iNVgvIr5Hgzoph3KrAx87ML7+Gvy/qyU7oAjewT8DgU CUMw== X-Gm-Message-State: APjAAAU01YH/GCLwm4lC4NjXuDOX/9cD5ohGdo2zDwMB/bf892CHWwnn hbpbaf7rfUcIPtjBM/xyYQqFHmD3kggBmN908aPwgg== X-Google-Smtp-Source: APXvYqxVUrlRlBzkiByeoyFdu4dQhtacOwZjB+QoHRf7avUupN3JCPic2FiiSx+ZwD9EBq9qIkKVUnOWHfb//Vf+hT8= X-Received: by 2002:a9d:7248:: with SMTP id a8mr5283755otk.363.1560532457937; Fri, 14 Jun 2019 10:14:17 -0700 (PDT) MIME-Version: 1.0 References: <1560366952-10660-1-git-send-email-cai@lca.pw> <1560376072.5154.6.camel@lca.pw> <87lfy4ilvj.fsf@linux.ibm.com> <20190614153535.GA9900@linux> <24fcb721-5d50-2c34-f44b-69281c8dd760@linux.ibm.com> <16108dac-a4ca-aa87-e3b0-a79aebdcfafd@linux.ibm.com> In-Reply-To: From: Dan Williams Date: Fri, 14 Jun 2019 10:14:06 -0700 Message-ID: Subject: Re: [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page() To: Jeff Moyer Cc: "Aneesh Kumar K.V" , Oscar Salvador , Qian Cai , Andrew Morton , Linux MM , Linux Kernel Mailing List , linux-nvdimm 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 Fri, Jun 14, 2019 at 10:09 AM Jeff Moyer wrote: > > "Aneesh Kumar K.V" writes: > > > On 6/14/19 10:06 PM, Dan Williams wrote: > >> On Fri, Jun 14, 2019 at 9:26 AM Aneesh Kumar K.V > >> wrote: > > > >>> Why not let the arch > >>> arch decide the SUBSECTION_SHIFT and default to one subsection per > >>> section if arch is not enabled to work with subsection. > >> > >> Because that keeps the implementation from ever reaching a point where > >> a namespace might be able to be moved from one arch to another. If we > >> can squash these arch differences then we can have a common tool to > >> initialize namespaces outside of the kernel. The one wrinkle is > >> device-dax that wants to enforce the mapping size, > > > > The fsdax have a much bigger issue right? The file system block size > > is the same as PAGE_SIZE and we can't make it portable across archs > > that support different PAGE_SIZE? > > File system blocks are not tied to page size. They can't be *bigger* > than the page size currently, but they can be smaller. > > Still, I don't see that as an arugment against trying to make the > namespaces work across architectures. Consider a user who only has > sector mode namespaces. We'd like that to work if at all possible. Even with fsdax namespaces I don't see the concern. Yes, DAX might be disabled if the filesystem on the namespace has a block size that is smaller than the current system PAGE_SIZE, but the filesystem will still work. I.e. it's fine to put a 512 byte block size filesystem on a system that has a 4K PAGE_SIZE, you only lose DAX operations, not your data access. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90C4DC31E4B for ; Fri, 14 Jun 2019 17:14:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2DACB2183E for ; Fri, 14 Jun 2019 17:14:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="sTwfKZMS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2DACB2183E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C774A6B0269; Fri, 14 Jun 2019 13:14:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C25276B026A; Fri, 14 Jun 2019 13:14:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AED846B026B; Fri, 14 Jun 2019 13:14:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by kanga.kvack.org (Postfix) with ESMTP id 873A56B0269 for ; Fri, 14 Jun 2019 13:14:19 -0400 (EDT) Received: by mail-ot1-f72.google.com with SMTP id 80so1446003otv.1 for ; Fri, 14 Jun 2019 10:14:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:mime-version:references :in-reply-to:from:date:message-id:subject:to:cc; bh=1DOR0lfku3yUBhnRNWEqeIw9f7cV+CNTtUVXtGntF+g=; b=JrFv16i5wDZfzOavVw/C8sfHuamBdFagUtX/DKzAP+dlLswxEpNWCyTu5ho2UgivlO 0PUACwory8iRAvNkUQ7hOZrGUzw8VxD+AxhPsfSCDYyoZIZZpKgIaM5Vm30DG9P8zv/C Ey7mY11ntNx8cTauiOWVBMd7EKrqOoWZlj+Z/C3uXy2yq6wGCJT8AlOSYNxHU0rRXYNI BjQfWi15K9OxoU8QwF5JPqbK6lHLBOFpmaCd9wEHu2ZsgtlAnMQMGhlkyCXL787lQg63 tYZUqsqnCPaO4pHaeOWrcLZjthDUPUr37ctTSB8TjlD/BmFV9ePBq1c0P9iRzIhD6rIF mHzA== X-Gm-Message-State: APjAAAUNUwmYa0hhwX8MHOItA3Qttv/Tkoea98ZZoRjEDlEUvQIj85JS x94LQJ9vhXqeBqoxEdOeNqzaTb9x3PB2mZr1w+z6CQsJhN2Kn2S32whoLoTa+BYsNXEB7Omk1oB Ksxce+j7lN31eawgpZbkH1KmtPTJp/d/LSzyGAK7vlZwANUqvmMWbpsePb3ki7xizXQ== X-Received: by 2002:aca:4404:: with SMTP id r4mr2471407oia.130.1560532458787; Fri, 14 Jun 2019 10:14:18 -0700 (PDT) X-Received: by 2002:aca:4404:: with SMTP id r4mr2471388oia.130.1560532458192; Fri, 14 Jun 2019 10:14:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560532458; cv=none; d=google.com; s=arc-20160816; b=k09pxZGCtfO9w9TmwQ6iZ7gCxXG5gGj5VZZEbKc+aDMEFSvMxboTGNGuf7SsSUCgnE XbZAi++jy3Pi2OGBq17R7+0rsMd+4VFe0sUXz/dg4TYMYhHAtlk2qm0Q0L6XIK68VqX1 nzgxvDNEIFcLCM+tR+z2HRSlK3GCW+6+s3+BDcecsV6XF7gLn9cNuesV9WJOPtNioQoH WCWd9Ij5TOxRCCpta7Hnlar4syWOnFDqwIAz/zkHBcI/Pr6aRk443LAh8hSrpcWTbKG4 MZGL1rdokS2H/htJ4ctx1PyfbakOaA07d9BJqylAzEio5y2hBg0Lzs8br4Sxp333bb71 oEtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=1DOR0lfku3yUBhnRNWEqeIw9f7cV+CNTtUVXtGntF+g=; b=AIcetw6pthrsa2EOPUm2pTIcYmh0pesWo51jfD3iqakXTWHtWnmHi8h6upNy267yN0 1g3rvPhZoj4GOLxIwNH79wNT9stbHkTb+SBoyeP63uIutW8fr1BzbyoAk/1SCxhhifRa tgvTBziGcSMcD0AhNFUohCO0S74PQ4pZ+slssCSOdgOTh2CdUalI2L0PssWqptNdf485 K5OTnI/PdTDubMnGZF6YhRGdV43m3nzrywyZ9i2EkpVgQvY0u0WMQnzyewLYFOzQrODt u1AQh7q+EnEjkwzX7Y3MbOlFuRgSROSstDm6pN07QvogaEeEtstW8nNoK5vSMJ0Hb0rp 0sVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=sTwfKZMS; spf=pass (google.com: domain of dan.j.williams@intel.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=dan.j.williams@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id k3sor1906068otc.90.2019.06.14.10.14.18 for (Google Transport Security); Fri, 14 Jun 2019 10:14:18 -0700 (PDT) Received-SPF: pass (google.com: domain of dan.j.williams@intel.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=sTwfKZMS; spf=pass (google.com: domain of dan.j.williams@intel.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=dan.j.williams@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com 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=1DOR0lfku3yUBhnRNWEqeIw9f7cV+CNTtUVXtGntF+g=; b=sTwfKZMStgwHohmnokMWPy+VfqEaV8lW2lueb7v8fb896+Vc0aKVzpBH0A2lEJlw6q oALCiHx77zWRNARo52nz8z+FNUxgUwVgBG+v1ofG044GSZOat+JTG9E2WNwyxxib8AG2 gpjqossClsMvuhpes7lVdiSsvyVheT+RRZNuZS9QKm7gxXA0LXlU62z/ZeDVSIkaSKLG q2xdj1lK+22SHsQoDVfk25zVhm3/u/GXGDlHpOQpCSDX6j/uZMH4LMgtT9/w9S6/Uurk O8qQF4zoQsEqPbLE2I2goSlCiHkrB1+UDrJXIaIzjBrMd5fRfGm+SSdXADa62AeNqAyv 0hiQ== X-Google-Smtp-Source: APXvYqxVUrlRlBzkiByeoyFdu4dQhtacOwZjB+QoHRf7avUupN3JCPic2FiiSx+ZwD9EBq9qIkKVUnOWHfb//Vf+hT8= X-Received: by 2002:a9d:7248:: with SMTP id a8mr5283755otk.363.1560532457937; Fri, 14 Jun 2019 10:14:17 -0700 (PDT) MIME-Version: 1.0 References: <1560366952-10660-1-git-send-email-cai@lca.pw> <1560376072.5154.6.camel@lca.pw> <87lfy4ilvj.fsf@linux.ibm.com> <20190614153535.GA9900@linux> <24fcb721-5d50-2c34-f44b-69281c8dd760@linux.ibm.com> <16108dac-a4ca-aa87-e3b0-a79aebdcfafd@linux.ibm.com> In-Reply-To: From: Dan Williams Date: Fri, 14 Jun 2019 10:14:06 -0700 Message-ID: Subject: Re: [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page() To: Jeff Moyer Cc: "Aneesh Kumar K.V" , Oscar Salvador , Qian Cai , Andrew Morton , Linux MM , Linux Kernel Mailing List , linux-nvdimm Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jun 14, 2019 at 10:09 AM Jeff Moyer wrote: > > "Aneesh Kumar K.V" writes: > > > On 6/14/19 10:06 PM, Dan Williams wrote: > >> On Fri, Jun 14, 2019 at 9:26 AM Aneesh Kumar K.V > >> wrote: > > > >>> Why not let the arch > >>> arch decide the SUBSECTION_SHIFT and default to one subsection per > >>> section if arch is not enabled to work with subsection. > >> > >> Because that keeps the implementation from ever reaching a point where > >> a namespace might be able to be moved from one arch to another. If we > >> can squash these arch differences then we can have a common tool to > >> initialize namespaces outside of the kernel. The one wrinkle is > >> device-dax that wants to enforce the mapping size, > > > > The fsdax have a much bigger issue right? The file system block size > > is the same as PAGE_SIZE and we can't make it portable across archs > > that support different PAGE_SIZE? > > File system blocks are not tied to page size. They can't be *bigger* > than the page size currently, but they can be smaller. > > Still, I don't see that as an arugment against trying to make the > namespaces work across architectures. Consider a user who only has > sector mode namespaces. We'd like that to work if at all possible. Even with fsdax namespaces I don't see the concern. Yes, DAX might be disabled if the filesystem on the namespace has a block size that is smaller than the current system PAGE_SIZE, but the filesystem will still work. I.e. it's fine to put a 512 byte block size filesystem on a system that has a 4K PAGE_SIZE, you only lose DAX operations, not your data access.