Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3422139pxm; Mon, 28 Feb 2022 20:12:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJykcOMV0kKNWbOmZ6yqwLAuJ7bTn1ho7J9WwT3AW0A5D2pgyLfnjHq8pM8UXXCCP+SEaF0W X-Received: by 2002:a17:90b:1a81:b0:1bc:ec26:40a6 with SMTP id ng1-20020a17090b1a8100b001bcec2640a6mr20105375pjb.0.1646107950337; Mon, 28 Feb 2022 20:12:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646107950; cv=none; d=google.com; s=arc-20160816; b=PwlaYZcF1tdhHyT7kao0kVl6U9if4i8xGgf89n86mgsx7EusAfpC/iPa0dpMQn2UWk 8x+xTLnv8qSdJF4XkOuicQL3w4JV01+ZgK/shUk/iIvElKMErH1QlTBSOZhXLEquWMUR QTC+E66emXlyiueuoQvEo+a1FISJuClaOmn/qfQlFthuEbxBMgRT2ijyT7CDGH1bdPu4 J5oY0ohu1M1xaYenfjjIRQjkAeGZ/YLMF/hInxH7Dde55VOX5j/6iYWX11zNk3/0sNbT wXvA373ZdelEKpDFMlf4vx6drLDgJMriDJT8k6DnZY/DhQjCc6hPEsORKFaoREE0lRVz R0mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=T0AjxvjFrHR6fu2oGFLcKZSFRRlXKq1Dcqtae0GYicM=; b=TENGEd0ypsCliEUpkf3bBtqoLpmoq4D4WF6WOmC3W2NSfZ6GEp6+79nGW4JqKSLzTz Sw9AVM/bZeSNSCeq/mvfq0e2Wxmk4PvguLlobllDz117gVup40ww/rCu8R4+KbpbIs2U HgfGhJmv0ysRojtewqYJMZV0Xmk2TmzB2DzH7Z7tHJ2g+QM622IobdACpPs9UekqmAvy DMkGiSIZw1RWVtSR16vcnZ6iEOMm0fMN6Rh6qwwM9JVDYjrqaPQKi/3RigNn+wWOz3m8 2AHOcyUJtfc56FyvV0Rkub4AadSVPWeyxHHJD/LYWIVV5pxWKSKejG51xWZV3BvMjZsf 6LLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=zI7OFwma; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e9-20020a170902e0c900b0015182573b59si812119pla.246.2022.02.28.20.12.12; Mon, 28 Feb 2022 20:12:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=zI7OFwma; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231130AbiCADQQ (ORCPT + 99 others); Mon, 28 Feb 2022 22:16:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230381AbiCADQO (ORCPT ); Mon, 28 Feb 2022 22:16:14 -0500 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E92D25133F for ; Mon, 28 Feb 2022 19:15:33 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id p19so24602680ybc.6 for ; Mon, 28 Feb 2022 19:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T0AjxvjFrHR6fu2oGFLcKZSFRRlXKq1Dcqtae0GYicM=; b=zI7OFwma/V9whbuWLP6/dekw2Ef4XO1BHT/odjfXiqqBSBN3wNRSaGlW2e5S3DMHh7 6nafsyPBh4XZpyLf2y8+bx1wiOP4m/XVyOhznsE0nDLtBWURJEZWY5eN+FSlXebfO/aq MwUsslVUGDBvCplLbj0DodURsvuHlZKfRKRtG0HI9/Ohu/g8Fmg0lYEl7PCIAzTcnaWE Up6KvQB5PLEdim8+dqyWUZVrTMjwU+YF2tRj6Iur3Wzj7yuugcJee25X7gymnZVLr5Q2 EiswuU88iHSTSH58Nu6p49kDjlzAq1dGIhw6LjEOdmlf7xGuc1AM4V3PFzyIodKR2Uzv nGpw== 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=T0AjxvjFrHR6fu2oGFLcKZSFRRlXKq1Dcqtae0GYicM=; b=UkUThAF+DFMGgDtCGJvUY3O1B4qupDpbRw1flSm/+qu11TrHDjUPnGjvBYE+oYavIk GKvvS3RJo0uMuVjyi3eB4F9K5sCGgUlibhdg1/T2QjC+fXt0pPbknm2aMpZqajII0Axq OB0xJTvyk+eJq1FyQ5QiiXPbdEkp/n5n9XIphFiLHuPmrGgrLfyNqCKiVFBoet184ATz Ic2+Q+aoOE8ZUJ9dXTfMRlSunaEJco/Qwo+BkV8WqaF+obLYBFex0c9x3K55+Rd1PzKv K9UJzcS8pZF+PfmBNuajJIIPAnUhiqOurjkGkrgs0R9/OAztSPAr6SqEdlkj++zx11LD 8L/Q== X-Gm-Message-State: AOAM533pzn72PipgKX+TKkGfdwBkhxqsUPP5666Tj/TdrqhlvuMQ/6EB MBUU0NH61q5AErho+QpNXdXjcP3aP2ycz/k0N6bBcQ== X-Received: by 2002:a25:3d87:0:b0:61e:170c:aa9 with SMTP id k129-20020a253d87000000b0061e170c0aa9mr21333575yba.89.1646104533214; Mon, 28 Feb 2022 19:15:33 -0800 (PST) MIME-Version: 1.0 References: <20220228063536.24911-1-songmuchun@bytedance.com> <20220228063536.24911-5-songmuchun@bytedance.com> <20220228132606.7a9c2bc2d38c70604da98275@linux-foundation.org> In-Reply-To: <20220228132606.7a9c2bc2d38c70604da98275@linux-foundation.org> From: Muchun Song Date: Tue, 1 Mar 2022 11:14:53 +0800 Message-ID: Subject: Re: [PATCH v3 4/6] mm: pvmw: add support for walking devmap pages To: Andrew Morton Cc: Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Alistair Popple , Yang Shi , Ralph Campbell , Hugh Dickins , Xiyu Yang , "Kirill A. Shutemov" , zwisler@kernel.org, Christoph Hellwig , linux-fsdevel , nvdimm@lists.linux.dev, LKML , Linux Memory Management List , Xiongchun duan , Muchun Song Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 1, 2022 at 5:26 AM Andrew Morton wrote: > > On Mon, 28 Feb 2022 14:35:34 +0800 Muchun Song wrote: > > > The devmap pages can not use page_vma_mapped_walk() to check if a huge > > devmap page is mapped into a vma. Add support for walking huge devmap > > pages so that DAX can use it in the next patch. > > > > x86_64 allnoconfig: > > In file included from : > In function 'check_pmd', > inlined from 'page_vma_mapped_walk' at mm/page_vma_mapped.c:219:10: > ././include/linux/compiler_types.h:347:45: error: call to '__compiletime_assert_232' declared with attribute error: BUILD_BUG failed > 347 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > | ^ > ././include/linux/compiler_types.h:328:25: note: in definition of macro '__compiletime_assert' > 328 | prefix ## suffix(); \ > | ^~~~~~ > ././include/linux/compiler_types.h:347:9: note: in expansion of macro '_compiletime_assert' > 347 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > | ^~~~~~~~~~~~~~~~~~~ > ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' > 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > | ^~~~~~~~~~~~~~~~~~ > ./include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' > 59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") > | ^~~~~~~~~~~~~~~~ > ./include/linux/huge_mm.h:307:28: note: in expansion of macro 'BUILD_BUG' > 307 | #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; }) > | ^~~~~~~~~ > ./include/linux/huge_mm.h:104:26: note: in expansion of macro 'HPAGE_PMD_SHIFT' > 104 | #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) > | ^~~~~~~~~~~~~~~ > ./include/linux/huge_mm.h:105:26: note: in expansion of macro 'HPAGE_PMD_ORDER' > 105 | #define HPAGE_PMD_NR (1< | ^~~~~~~~~~~~~~~ > mm/page_vma_mapped.c:113:20: note: in expansion of macro 'HPAGE_PMD_NR' > 113 | if ((pfn + HPAGE_PMD_NR - 1) < pvmw->pfn) > | ^~~~~~~~~~~~ > make[1]: *** [scripts/Makefile.build:288: mm/page_vma_mapped.o] Error 1 > make: *** [Makefile:1971: mm] Error 2 > > > because check_pmd() uses HPAGE_PMD_NR and > > #else /* CONFIG_TRANSPARENT_HUGEPAGE */ > #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; }) > > I don't immediately see why this patch triggers it... Maybe the reason is as follows. The first check_pmd() is wrapped inside `if (pmd_trans_huge(pmde))` block, since pmd_trans_huge() just returns 0, check_pmd() will be optimized out. There is a `if (!thp_migration_supported()) return;` block before the second check_pmd(), however, thp_migration_supported() returns 0 on riscv. So the second check_pmd() can be optimized out as well. I think I should replace `pmd_leaf` with `pmd_trans_huge() || pmd_devmap()` to fix it. Thanks.