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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC6DDC433EF for ; Fri, 5 Nov 2021 16:41:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C4C66126A for ; Fri, 5 Nov 2021 16:41:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8C4C66126A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A29D3940007; Fri, 5 Nov 2021 12:41:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D90E6B0071; Fri, 5 Nov 2021 12:41:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A069940007; Fri, 5 Nov 2021 12:41:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 7BF936B006C for ; Fri, 5 Nov 2021 12:41:31 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 237C018525C13 for ; Fri, 5 Nov 2021 16:41:31 +0000 (UTC) X-FDA: 78775442382.30.5B472D3 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf04.hostedemail.com (Postfix) with ESMTP id AD9A450000B6 for ; Fri, 5 Nov 2021 16:41:18 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id n23so8813118pgh.8 for ; Fri, 05 Nov 2021 09:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5amwjTWIRqLe2fTBGlO6hAxlM9gBL72qHsZ42zn9EgA=; b=w2UkjvmMa0b3Jj3bRnCOzLOOnJhzHram0qUr+hyVoF7QF9wO0sS98CValsAS4SqqGs bJ9t/C20kldIAxthpkaMWhjpJgzWIlNQDDNN5E+rqF+YU7F1SGGuyX8PDpHk8SudRGlQ zw2wsAtBlstMfy+CtBPresI5dAl4hU2isZxvNFFptJ4pa4O4izJIV2fD2GUXU6eS+jah kKKiufRF1OgboBlVcSu8bleHvoc0e/emRjRHSuPKNAtlXDaPJ9MCPEgbxIWIxEzZJCSE 0JrTPTicicUFnp/AAJ/njGjb9Bl+Ka1UvAchQ2vB4em9ZYUfNBe/4jBKFac75OxFICzw XrnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5amwjTWIRqLe2fTBGlO6hAxlM9gBL72qHsZ42zn9EgA=; b=wBezd6wzo1kUSUMjaY9jNVGMZ1rTWbxBSSuJuP01Q2thCkFS8ZqKUyZVXM4M5rdiTU YTBfXgXXL+iqJk/ARUKIGdmAoG5rJ3wwGqL36pPg91nOJQR1KKekJcMYwaTY0ow/6dQv EFbwUqVHr4nE7SfKbrkoeS/8XrbpeSaiS3FQ84qrt+weqdDvrnN+WVIf2C1EEYzzpf9e P/fckSSNIrLLKT3ZVtMRjW6X62FCQMW5xrV6VPGp0udYZefpUCZc9+Kibhjs0E7n/wVP p4RrUpD5ZKEhC1lbHGLJueXLzIQ+XMBs1fwMMa76UAXEGBmZEkCphea1LUYzZJE3NhS2 0sSg== X-Gm-Message-State: AOAM5315bEO6ca1580MS8JmndrNomgyYzZf5ZuUsEuBHXE3fd3i9Xp8N 3xXMLUHy5QXokqtQOhI83Y2cFJqMR02gddLEQNAIBQ== X-Google-Smtp-Source: ABdhPJy88KlTg/YTg27YWTdBpEzIk+qBEUkjukz8u9LiS5ucVjPUeY/wW29fEVui4yjEuSG2RwuDHI2MPSDUqYsWP6o= X-Received: by 2002:a63:6302:: with SMTP id x2mr27989241pgb.5.1636130486183; Fri, 05 Nov 2021 09:41:26 -0700 (PDT) MIME-Version: 1.0 References: <20210827145819.16471-1-joao.m.martins@oracle.com> <20210827145819.16471-8-joao.m.martins@oracle.com> In-Reply-To: From: Dan Williams Date: Fri, 5 Nov 2021 09:41:15 -0700 Message-ID: Subject: Re: [PATCH v4 07/14] device-dax: compound devmap support To: Joao Martins Cc: Linux MM , Vishal Verma , Dave Jiang , Naoya Horiguchi , Matthew Wilcox , Jason Gunthorpe , John Hubbard , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , Linux NVDIMM , Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AD9A450000B6 X-Stat-Signature: e6wosrgp4mqa5ugxpfnx69rqge46s7up Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=w2UkjvmM; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf04.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.173) smtp.mailfrom=dan.j.williams@intel.com X-HE-Tag: 1636130478-601416 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, Nov 5, 2021 at 7:10 AM Joao Martins wrote: > > On 11/5/21 00:38, Dan Williams wrote: > > On Fri, Aug 27, 2021 at 7:59 AM Joao Martins wrote: > >> > >> Use the newly added compound devmap facility which maps the assigned dax > >> ranges as compound pages at a page size of @align. Currently, this means, > >> that region/namespace bootstrap would take considerably less, given that > >> you would initialize considerably less pages. > >> > >> On setups with 128G NVDIMMs the initialization with DRAM stored struct > >> pages improves from ~268-358 ms to ~78-100 ms with 2M pages, and to less > >> than a 1msec with 1G pages. > >> > >> dax devices are created with a fixed @align (huge page size) which is > >> enforced through as well at mmap() of the device. Faults, consequently > >> happen too at the specified @align specified at the creation, and those > >> don't change through out dax device lifetime. > > > > s/through out/throughout/ > > > >> MCEs poisons a whole dax huge page, as well as splits occurring at the configured page size. > > > > A clarification here, MCEs trigger memory_failure() to *unmap* a whole > > dax huge page, the poison stays limited to a single cacheline. > > > Ah, yes. I'll fix it for v5. > > > Otherwise the patch looks good to me. > > > Thanks! > > Btw, does 'looks good' == Reviewed-by (with the commit message clarification above) or is > it that 'should be good with the ammend above and you get the tag in the next round' ? Reviewed-by: Dan Williams > Asking as IIRC you mentioned this too some other time(s) (in the simpler sparse-vmemmap > patches) hence just clarifying to understand your expected 'process' better. > > Also, I will be splitting this series as mentioned in the other discussion ... > > https://lore.kernel.org/linux-mm/20211019160136.GH3686969@ziepe.ca/ > > ... So this patch and the previous one should be the last two patches of the series > and the rest (gup, sparse-vmemmmap) will go in parallel. Sounds good.