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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F194C61DF4 for ; Fri, 24 Nov 2023 09:06:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC6488D0069; Fri, 24 Nov 2023 04:06:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A4EF68D0063; Fri, 24 Nov 2023 04:06:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A1958D0069; Fri, 24 Nov 2023 04:06:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 75C218D0063 for ; Fri, 24 Nov 2023 04:06:09 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 47312140EAE for ; Fri, 24 Nov 2023 09:06:09 +0000 (UTC) X-FDA: 81492266058.27.7CD42A1 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf25.hostedemail.com (Postfix) with ESMTP id 5CA4BA000A for ; Fri, 24 Nov 2023 09:06:07 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700816767; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lJGBGZlFxhbpxnAT7Gsiax5Mi3O89lnBnAbe3YyVYo0=; b=zhc36/pCHCigL40kE64NQKEeccqPGbdeGrn73o5Y6pPB9wvvByYCUgKpaVYyzf05SbWP13 ERIkq1KI4mHhbdskIBzw2yhzgmQdZfxia9SxMVOiVWe/X7vRj0S9fumBN70gxkGIpii1lJ uwy7GFJhPKN4ZQ/J1vwCijCkG1nRrmE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700816767; a=rsa-sha256; cv=none; b=rv1q4L/snlikB0QpHwAjX8t4Yd64Ivvqh4ZYysjS1z5C59JFK8TRQ3fr63mxzI0vHDCYD6 h3Jc+pQORm0BKH8z/izpZvonYxRy5IsqS+Df1p70pXQ6Pt2qGE9NUFQes5lz/jKNI8iUiF 8P2/lAK546OhyTWXHWwTkmTBxh3GXh4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 B74521063; Fri, 24 Nov 2023 01:06:52 -0800 (PST) Received: from [10.57.71.2] (unknown [10.57.71.2]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 64DC23F73F; Fri, 24 Nov 2023 01:06:03 -0800 (PST) Message-ID: <510adc26-9aed-4745-8807-dba071fadbbe@arm.com> Date: Fri, 24 Nov 2023 09:06:01 +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: 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-1-peterx@redhat.com> <20231116012908.392077-7-peterx@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5CA4BA000A X-Rspam-User: X-Stat-Signature: 5i8oxhy9annp7bpccjsjcgmspc1rbd9u X-Rspamd-Server: rspam03 X-HE-Tag: 1700816767-718276 X-HE-Meta: U2FsdGVkX1+wLvRdXUKGK96Jbj+FowiduoOuruvgiLMeo71lZM/F0AFSqTRO2On3o+wXVX8Kdq21AW73MJ33kOuHdJ3k/ti2ebuYMEsHAPSTTgtWsk0FTzLOzeO/yUpUKaX3Elw/92DM/B11WEm5+tVDAsZDUUA6aa1LBJVuBcV0hjWuzNOtdSROwNpdOsY6NCx6p65AlRo+1ZdXGJcXWrXQzzTJio+4EDDIugs+izTUCx42Q4hvbSONYxbthp9Nacol+lPAIjfJLx3oFCetc4S43hscNYChvN3yMlegvc4WlD+Bwp711OqRttNywaoStKKzIRMWCtbXtdNxtQ/BXc0RLV5QbA/Fzg2O6Fcv8UnBzghBHfUKb9oKtbM1rPvrX9r+X0wEYwAGnmAu/5unL9Sp01rCmXrPivLPDhU5iO0F8HT3yF4pKOs6xYuMFAgBDd2xWfraVGXSAqrTNXZ4jzHiXQoHz663h6Zz/PLiwlNV2+fXdt2O+azeXvsFrNi6KDOr3nzlUlld+jg5tAAnAGPybajfj0uF7rawflUmatwDWM1JJ8zAJclfkeMavQmgKhYnkmnmm800tEFW73g85otTcCsGL95GaVl1nKuRyENP2pYooE5KUX1XzQSrF1HToB1x6dGQ4iRAgHZ/n2BpVz4G3eIGEXYoVrPpoF/d7G+NP5vH6waTbgyTaNu9M+KV9ICED99TenkIcKCLnm4n2EmKlwDwls7/vmQZu4Jn6uWmwjXVeJX9/vAcAE4lauTVdSQCyydD4sKIERICIj0ZuFGdXr56vZQMx1jcBH/2TuG95vuNfDgt2qEftD47ln/5qdSIMB+l2S6Zipd6RJli11yuJZ44jkd2xy/BAqBNhLdrUadH11qPUiAVegMHIWZIuDxitFPYFlEB8wgo8gbhIMZGySImive8pHzSsr/2anHk494ykEcKChZ2QbBFO8rzvOBYRt99mF4fAsrA5gY BpAZIP0L o62BZ3Vcg5vFSFE7ADOf+tXzm3mgD2FaxfaXEaYK1zS/v8fEBMiYaJQH2pkld6bzs/Ry35We7FuWpyW2BgZvoPB/xHol55Sj/W9uEZV+00nl3oucZsdtueX5L02in4brcjjSeN9MngaDSHeDWAXU9QjhPBAfdX1o+yNiG09nZj1qXuBiw5XAGFPEQna6grOqSs/ggsrwYugCtRpwjDGSIDcFu9r+5D0AJJ9zylW8mqxOZRgxHKGUpyDRjcEMKgZPmD82/gz5DQrejNzQyy6Fb7utQJ6n8FpoxRmRJY5XftRPoQEcltbGwKStLQbew04GKHBqF 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: List-Subscribe: List-Unsubscribe: On 23/11/2023 19:46, Peter Xu wrote: > On Thu, Nov 23, 2023 at 07:11:19PM +0000, Ryan Roberts wrote: >> Hi, >> >> I'm not sure I've 100% understood the crossover between this series and my work >> to support arm64's contpte mappings generally for anonymous and file-backed memory. > > No worry, there's no confliction. If you worked on that it's only be > something nice on top. Also, I'm curious if you have performance numbers, I have perf numbers for high level use cases (kernel compilation and Speedometer Java Script benchmarks) at https://lore.kernel.org/linux-arm-kernel/20230622144210.2623299-1-ryan.roberts@arm.com/ 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. > because I'm going to do some test for hugetlb cont_ptes (which is only the > current plan), and if you got those it'll be a great baseline for me, > because it should be similar in you case even though the goal is slightly > different. > >> >> My approach is to transparently use contpte mappings when core-mm request pte >> mappings that meet the requirements; and its all based around intercepting the >> normal (non-hugetlb) helpers (e.g. set_ptes(), ptep_get() and friends). There is >> no semantic change to the core-mm. See [1]. It relies on 1) the page cache using >> large folios and 2) my "small-sized THP" series which starts using arbitrary >> sized large folios for anonymous memory [2]. >> >> If I've understood this conversation correctly there is an object called hugepd, >> which today is only supported by powerpc, but which could allow the core-mm to >> control the mapping granularity? I can see some value in exposing that control >> to core-mm in the (very) long term. > > For me it's needed immediately, because hugetlb_follow_page_mask() will be > gone after the last patch. > >> >> [1] https://lore.kernel.org/all/20231115163018.1303287-1-ryan.roberts@arm.com/ >> [2] https://lore.kernel.org/linux-mm/20231115132734.931023-1-ryan.roberts@arm.com/ > > AFAICT you haven't yet worked on gup then, after I glimpsed the above > series. No, I haven't touched GUP at all. The approach is fully inside the arm64 arch code (except 1 patch to core-mm which enables an optimization). So as far as GUP and the rest of the core-mm is concerned, there are still only page-sized ptes and they can all be iterated over and accessed as normal. > > It's a matter of whether one follow_page_mask() call can fetch more than > one page* for a cont_pte entry on aarch64 for a large non-hugetlb folio > (and if this series lands, it'll be the same to hugetlb or non-hugetlb). > Now the current code can only fetch one page I think. > > Thanks, >