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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 0D713C07E94 for ; Fri, 4 Jun 2021 15:58:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9FAF613E9 for ; Fri, 4 Jun 2021 15:58:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9FAF613E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1DD716B00A7; Fri, 4 Jun 2021 11:58:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A1E06B00A9; Fri, 4 Jun 2021 11:58:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06A286B00AA; Fri, 4 Jun 2021 11:58:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id C92E16B00A7 for ; Fri, 4 Jun 2021 11:58:46 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6311682499B9 for ; Fri, 4 Jun 2021 15:58:46 +0000 (UTC) X-FDA: 78216499452.07.26758C8 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf03.hostedemail.com (Postfix) with ESMTP id DEC9AC01C097 for ; Fri, 4 Jun 2021 15:58:27 +0000 (UTC) Received: by mail-oi1-f169.google.com with SMTP id h9so10211773oih.4 for ; Fri, 04 Jun 2021 08:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Rhqoy6MY7EfOz8skYLjiR46KThNMAlNLitSfpvspEOE=; b=VWs4Ft09ePRlQVMbF6OkH6QZIrxW4iolcEcZ+Nt6BAwiWfEMw4rx8ZKo3nYOouKJeH 4o8U0ijASb+UsRT+zm68+uVMfTzT3QsDFS/ShNHG2xFNSieE8lWf2eYqNyN6VCw26v4+ 8MHrpa5LQ3uQTGpO62eoi09ZWVAvP0xfhjgS3Oe9EgJpabsxf6BDDAVZ8eBhT+ApLeof 6jwefViyOj1YC13Q6gykLk97nE0D9desp7yRtE8USN3FPwXWJSu1jiQj72/0z2CkJU/U 0Cf229B+b41ZRV/5sqn2LWTXZ+cZj2FYJ6/SSt4IEP7QVUk0hq2cgL7+N38aSPeKa/fX 358w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Rhqoy6MY7EfOz8skYLjiR46KThNMAlNLitSfpvspEOE=; b=jVQj8Llg80BK/1MUPy27RP79Brx7TVeouq+Ol9bzFqQS8IjO5doJSggxJtadaHn6cA u0eufgkHXC76GUDZJkZ7SiY2kZJVNpyTV8mpyBcjSkoMoSTT3rc9C6cf5eN4823j+qHs CaknFnsUxsgI0neEjJiSfjAW8Et0EPv6QfNR5akAx6xO6XUGmG3dwJa0oF7FV6RzT5ft ZwZVqwPekrpoQTKqzy4Z+gT9g5Rzc8bdhRO9kfA4RZ2vz0D8qBqleS5CecuRNEmi4cOz ewbwZ/uBOd3wskYlLMiUo5WVs7iCHmDLYeOTyVpnUjyrbDggyF2tgX2uNj1oW6glbkbu BJMQ== X-Gm-Message-State: AOAM530ujije7LQoHTUTtgkIX3zFBe9CJH0xBNEnpJA7fQRW/HNbL09v 8ROnapNW303x2hJIqkXJ6Inleqot4bwDGQ== X-Google-Smtp-Source: ABdhPJxwDvhE1O00g2lojLJgHXNo1TIt6Pbg8B0Q99pRi6w4FlIw45etfKPCelL6vgMTkTwN5cYq4A== X-Received: by 2002:a17:90a:460d:: with SMTP id w13mr5656251pjg.35.1622821825138; Fri, 04 Jun 2021 08:50:25 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id w26sm2529767pgl.50.2021.06.04.08.50.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 08:50:24 -0700 (PDT) Date: Fri, 4 Jun 2021 15:50:20 +0000 From: Sean Christopherson To: Matthew Wilcox Cc: Yang Shi , Andrea Arcangeli , linux-mm@kvack.org, Paolo Bonzini , kvm@vger.kernel.org, Will Deacon , Marc Zyngier Subject: Re: PageTransCompoundMap confusion Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: m6h7wnwkpim6sqwhokto3bonxqiexdhm X-Rspamd-Queue-Id: DEC9AC01C097 X-Rspamd-Server: rspam02 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=VWs4Ft09; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of seanjc@google.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=seanjc@google.com X-HE-Tag: 1622822307-566321 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: +Will and Marc On Fri, Jun 04, 2021, Matthew Wilcox wrote: > I'm a bit confused about what PageTransCompoundMap() is supposed to do. > What it actually does is check that the specific page (which may or > may not be a head page) is not mapped by a PTE. I don't understand why > you'd care how some (other?) process does or does not have it mapped. > What I _think_ you want to know is "Can I map this page with a PMD entry > in the guest". And the answer to that is simply: > > bool kvm_is_transparent_hugepage(kvm_pfn_t pfn) > { > struct page *head = compound_head(pfn_to_page(pfn)); > return compound_order(head) >= HPAGE_PMD_ORDER; > } > > but maybe there's some reason you don't want to map hugetlbfs or other > sufficiently large compound pages with PMDs? > > Looking at the one caller of kvm_is_transparent_hugepage(), I'd be > tempted to inline the above into transparent_hugepage_adjust() > and call get_page() directly instead of indirecting through > kvm_get_pfn(). arm64 is the only remaining user of kvm_is_transparent_hugepage(). x86 purged its usage a while back, and instead looks at the host PTEs via lookup_address_in_mm() to get the current mapping level. The motivation was to consolidate the hugepage logic for THP, HugeTLBFS, and DAX, and to naturally support both 2mb and 1gb for all flavors of hugepages. Could arm64 do something similar and kill off kvm_is_transparent_hugepage() entirely?