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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 E0276C47082 for ; Mon, 7 Jun 2021 21:57:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F45E61130 for ; Mon, 7 Jun 2021 21:57:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F45E61130 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 CF7E96B006C; Mon, 7 Jun 2021 17:57:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA8F46B006E; Mon, 7 Jun 2021 17:57:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B223C6B0070; Mon, 7 Jun 2021 17:57:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id 810C26B006C for ; Mon, 7 Jun 2021 17:57:29 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 212BD180AD804 for ; Mon, 7 Jun 2021 21:57:29 +0000 (UTC) X-FDA: 78228289818.21.0E4D594 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf27.hostedemail.com (Postfix) with ESMTP id 763998019140 for ; Mon, 7 Jun 2021 21:57:23 +0000 (UTC) Received: by mail-pf1-f178.google.com with SMTP id k15so14134212pfp.6 for ; Mon, 07 Jun 2021 14:57:25 -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=1gPdlyJaM9Fys743qj55JEQeJ2R3PSv9Ivj/ZS6vyPw=; b=tX6NiDePGIyfCriXl0nKJe0h9DOty2l1dKErn1h6NkjPCzY1Nih4tF4RbMghsVd2/v igwlGbQZvYKyKURJljTBdxdAnpxgDzLU9VGQQgQctL7pMq7hhwCVVck6+VYZbWZIDPrx WPeAUGrxwMrV5VzdNf+i3sCFBpalmlYvsb6bnWsUyOowegd3E7ougEEy60D48CfUArNb UeG3pSo6EAyltPl8XiAtU4Xl9y27UnteDgut8+44nrqFN0NKPerJA6lQg3Uy0XY8gOSY 6peRXgtKC2COAqy08mCH9/PcKfjPESVT2h+ZN5aALWqUsN0ksPhfTBQ7VQRD1tvIz9Jp 6aiA== 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=1gPdlyJaM9Fys743qj55JEQeJ2R3PSv9Ivj/ZS6vyPw=; b=LrxsoVHbDl7mt1jNQizrTZOSJXBAJPbsqmakTaNPrpSt2XOOv7p9KdaHBFHglUQFLD 3twMKm9xV2oAxxjWD6s6qYevvAQBoDM/ywyXJFWmBm7uEOLVol4i6syw1+lW8XGObLiF Q4Tn/wbtP43zsgAG4iDvYFSOlKu0Fa+zLv31JhMwHSRybCQ5KLeomD6gTbFZFwRActgJ 2ckCXFcsxyUMUjaZeEtYT8u5VXHqNd2E5gJ1PMSlCfKfWFODzdjhh0qo7LuZKkqxiSg9 aJ3ttKuBs5AvsysQ506wrtxxVhrzU0k3PVmOe/ZgcE1GmQSkFeQdk1q/hd608nPntH7x 0K7A== X-Gm-Message-State: AOAM5333omcms5EouY+Yb/zkhD+TRntLeenPmNV3JGsIiwoyfplV2JL3 AkNRoRQ+gt0uqVwzE9Ly7ASozI1sv61/zcxCu+/Urg== X-Google-Smtp-Source: ABdhPJxs8ADfEtgRQstVYP6meeHoIfi7ZhKe1swGTzQ8vQQcJ93k/cAtpwZhdSNITs1Ou9q/+RwcoTmkDkaVSTSHyP4= X-Received: by 2002:a05:6a00:234f:b029:2c4:b8d6:843 with SMTP id j15-20020a056a00234fb02902c4b8d60843mr18908056pfj.71.1623103044831; Mon, 07 Jun 2021 14:57:24 -0700 (PDT) MIME-Version: 1.0 References: <20210325230938.30752-1-joao.m.martins@oracle.com> <20210325230938.30752-5-joao.m.martins@oracle.com> <56a3e271-4ef8-ba02-639e-fd7fe7de7e36@oracle.com> <8c922a58-c901-1ad9-5d19-1182bd6dea1e@oracle.com> In-Reply-To: From: Dan Williams Date: Mon, 7 Jun 2021 14:57:14 -0700 Message-ID: Subject: Re: [PATCH v1 04/11] mm/memremap: add ZONE_DEVICE support for compound pages To: Joao Martins Cc: Linux MM , Ira Weiny , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Linux NVDIMM Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=tX6NiDeP; spf=none (imf27.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.210.178) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 763998019140 X-Stat-Signature: qdzpf6boej3dbafg8wr4bk7q6tzb5pz9 X-HE-Tag: 1623103043-555771 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 Mon, Jun 7, 2021 at 2:02 PM Joao Martins wrote: [..] > > But naming aside, I was trying to get at was to avoid a second geometry value validation > > i.e. to be validated the value and set with a value such as DEVMAP_PTE, DEVMAP_PMD and > > DEVMAP_PUD. > > Sorry my english keeps getting broken, I meant this instead: > > But naming aside, what I am trying to get at is to remove the second geometry value > validation i.e. for @geometry to not be validated a second time to be set to DEVMAP_PTE, > DEVMAP_PMD or DEVMAP_PUD. > > > That to me sounds a little redundant, when the geometry value depends on what > > align is going to be used from. Here my metnion of @align refers to what's used to create > > the dax device, not the mmap() align [which can be lower than the device one]. The dax > > device align is the one used to decide whether to use PTEs, PMDs or PUDs at dax fault handler. > > > > So separate concepts, but still its value dependent on one another. At least unless we > > want to allow geometry values different than those set by --align as Jane suggested. > > > > And I should add: > > I can maintain the DEVMAP_* enum values, but then these will need to be changed in tandem > anytime a new @align value is supported. Or instead we use the name @geometry albeit with > still as an unsigned long type . Or rather than an unsigned long perhaps making another > type and its value obtained/changed with getter/setter. No, feel free to drop the enum and use an explicit "geometry" value for the vmemmap.