Received: by 2002:a05:7412:b10a:b0:f3:1519:9f41 with SMTP id az10csp2629877rdb; Mon, 4 Dec 2023 03:11:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IH3raCEoI6i8jeMU6cc9F+58xwBhcA9mo4FwwY79awE1Y7XpzxRSCv2QrvvcYM5OWFLU53s X-Received: by 2002:a05:6358:724c:b0:16b:c64b:5dad with SMTP id i12-20020a056358724c00b0016bc64b5dadmr3949710rwa.10.1701688307941; Mon, 04 Dec 2023 03:11:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701688307; cv=none; d=google.com; s=arc-20160816; b=V8vbZHqeTC1eirOAlfUweIp9FYwHaiizBsnDxPfJ/B4HpcHAYUquL+88BrRQCbCOkK Y3+4pM7EZZVlO0FZzhdVpLxjtTwgm8WTY8MKzoeMNSoZdR2TGW/0lAnuln7hdXbbRt0q 3+IlROSh/Jp0YSC8bCGdzDDYrz6vcnRzaDNwkTQbKX7ViU6iIWaL+CHvRQd+LeI9JDF8 uVID0hy1HvRdFK0fGGPC4fsqwdQ4tZzcCjhwKaA0vaDnqV/x01eX/FCHoucfyG9pvWsF wg2qLvIfsYxiahzBl0HAeKej/tJ5SC5kEnYonqlCWWlNGQTbPAtiDf4ZSEXyR4d/mGpm PK0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=Aep5mmSPeSr4jywesXUA5jCgECfadxKNNHj8ePB8uiY=; fh=OB7GlU9sCqPAzlACpkDWlVmXNdhERa4r1BTg7Uuch40=; b=bQfNODxmvNBy1v7CXH+1uQlSMKXYM9Q2imEVLi3XSaAQW+mXzYOeiRzUTfuXusOOWi 7It5Kjzrk9pOSx8dHpLGAvTofofD3saSNlxjUcUzbRs4McRZL6T+9zVe9qRrFiZINQDT taA4TUW8Fk92hkZ/Ofq1Yqp83FSx9FZGeqOPpjSdRVvXQl4JT62Ynmv62INWRmXOh+Oj XWLJTXCoLja9KhVPgq7e4Lm9akaZw9V0Ih/l7xkFEmRBiUu3BitecUU0KJOvwOwoh0rI nJk8GR7sUx+HneNVwOvEcPo9tvAFVdPl8lmOMJ8w3B0IRiUW6SNpjm5Dwh14Wh60QIpv 4xqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id w3-20020a634903000000b005859aec9406si7800918pga.16.2023.12.04.03.11.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 03:11:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 5A0ED8060C8C; Mon, 4 Dec 2023 03:11:45 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230015AbjLDLL0 (ORCPT + 99 others); Mon, 4 Dec 2023 06:11:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229519AbjLDLLY (ORCPT ); Mon, 4 Dec 2023 06:11:24 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A1162CC for ; Mon, 4 Dec 2023 03:11:30 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8F63E152B; Mon, 4 Dec 2023 03:12:17 -0800 (PST) Received: from [10.57.73.130] (unknown [10.57.73.130]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6CCCE3F6C4; Mon, 4 Dec 2023 03:11:27 -0800 (PST) Message-ID: <01aad92f-b1e0-4f31-b905-8b1c2012ebab@arm.com> Date: Mon, 4 Dec 2023 11:11:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing Content-Language: en-GB To: Christophe Leroy , Peter Xu Cc: Matthew Wilcox , Christoph Hellwig , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Andrea Arcangeli , James Houghton , Lorenzo Stoakes , David Hildenbrand , Vlastimil Babka , John Hubbard , Yang Shi , Rik van Riel , Hugh Dickins , Jason Gunthorpe , Axel Rasmussen , "Kirill A . Shutemov" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , Mike Rapoport , Mike Kravetz References: <20231116012908.392077-7-peterx@redhat.com> <510adc26-9aed-4745-8807-dba071fadbbe@arm.com> <283da12c-14f1-4255-b3c4-ab933f3373c4@csgroup.eu> From: Ryan Roberts In-Reply-To: <283da12c-14f1-4255-b3c4-ab933f3373c4@csgroup.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 04 Dec 2023 03:11:45 -0800 (PST) On 03/12/2023 13:33, Christophe Leroy wrote: > > > Le 30/11/2023 à 22:30, Peter Xu a écrit : >> On Fri, Nov 24, 2023 at 11:07:51AM -0500, Peter Xu wrote: >>> On Fri, Nov 24, 2023 at 09:06:01AM +0000, Ryan Roberts wrote: >>>> I don't have any micro-benchmarks for GUP though, if that's your question. Is >>>> there an easy-to-use test I can run to get some numbers? I'd be happy to try it out. >>> >>> Thanks Ryan. Then nothing is needed to be tested if gup is not yet touched >>> from your side, afaict. I'll see whether I can provide some rough numbers >>> instead in the next post (I'll probably only be able to test it in a VM, >>> though, but hopefully that should still reflect mostly the truth). >> >> An update: I finished a round of 64K cont_pte test, in the slow gup micro >> benchmark I see ~15% perf degrade with this patchset applied on a VM on top >> of Apple M1. >> >> Frankly that's even less than I expected, considering not only how slow gup >> THP used to be, but also on the fact that that's a tight loop over slow >> gup, which in normal cases shouldn't happen: "present" ptes normally goes >> to fast-gup, while !present goes into a fault following it. I assume >> that's why nobody cared slow gup for THP before. I think adding cont_pte >> support shouldn't be very hard, but that will include making cont_pte idea >> global just for arm64 and riscv Svnapot. > > Is there any documentation on what cont_pte is ? I have always wondered > if it could also fit powerpc 8xx need ? pte_cont() (and pte_mkcont() and pte_mknoncont()) test and manipulte the "contiguous bit" in the arm64 PTE entries. Those helpers are arm64-specific (AFAIK). The contiguous bit is a hint to the HW to tell it that a block of PTEs are mapping a physically contiguous and naturally aligned piece of memory. The HW can use this to coalesce entries in the TLB. When using 4K base pages, the contpte size is 64K (16 PTEs). For 16K base pages, its 2M (128 PTEs) and for 64K base pages, its 2M (32 PTEs). > > On powerpc, for 16k pages, we have to define 4 consecutive PTEs. All 4 > PTE are flagged with the SPS bit telling it's a 16k pages, but for TLB > misses the HW needs one entrie for each 4k fragment. From that description, it sounds like the SPS bit might be similar to arm64 contiguous bit? Although sounds like you are currently using it in a slightly different way - telling kernel that the base page is 16K but mapping each 16K page with 4x 4K entries (plus the SPS bit set)? > > There is also a similar approach for 512k pages, we have 128 contiguous > identical PTEs for them. > > And whatever PAGE_SIZE is (either 4k or 16k), the HW needs one 'unsigned > long' pte for each 4k fragment. So at the time being when we define > PAGE_SIZE as 16k, we need a special pte_t which is a table of 4x > unsigned long. > > Wondering if the cont_pte concept is similar and whether it could help. To be honest, while I understand pte_cont() and friends, I don't understand their relevance (or at least potential future relevance) to GUP? > > Thanks > Christophe