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 E1CF9C67861 for ; Fri, 5 Apr 2024 21:42:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4EC066B0092; Fri, 5 Apr 2024 17:42:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 477326B0096; Fri, 5 Apr 2024 17:42:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EE596B0099; Fri, 5 Apr 2024 17:42:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1163C6B0092 for ; Fri, 5 Apr 2024 17:42:57 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9697F14034A for ; Fri, 5 Apr 2024 21:42:56 +0000 (UTC) X-FDA: 81976803552.23.CE8F01C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 5DD72120022 for ; Fri, 5 Apr 2024 21:42:53 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZnnysDkV; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712353373; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Nh8AZu/36vuzSfX/Je7NxWoNvpcer/hOQkOAQFaqnk4=; b=pSvOBj9GoP3q5dzCTmPS2zi59piGdZj8GxQr7/h0AXOXHMWvJTF5WErJl9CAVFLornC/cE vzJOotuHaIfFUwO+3tjclZBjqYp5GpP0UnHDsYxWcWj/wTrg2+0EsIHgX19BEFCdUC5o7l Mym7YFI+mfGDt4CndBGOdgUrQwhYuLE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZnnysDkV; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712353373; a=rsa-sha256; cv=none; b=1neNrta+8yae2LJnlS6tnM40T+LsqJq0rO5tGqup7yFzSlilNHUwizN186LPaO+4eGO5Eh Tn2gEUNam4ln09QshyWX+PD74CcXz0ueiCvKV97R9IW5sw8Xi1HBRE57y2LaIMhAnK4iog Mp7kxyRXi5pRjOmYNnNaYFMhJUKvPM8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712353371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Nh8AZu/36vuzSfX/Je7NxWoNvpcer/hOQkOAQFaqnk4=; b=ZnnysDkV95d3IkZdTauVM8cFRBBoqq9y3PdiELk4lqvlnNWeBNLPE37OLq8KMpvsR+FmDj 8kCti2lgZp9OCMg6qb2hnNvF1RagS4wNhD42eHq/ZS4Fv4whb7lGbYtRUUhfluofRNGLJj t6zeFeNaLQeq27wsHHGAX67eEzrL8fc= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-468-0CdprE60Nai2xXCuJFAl1w-1; Fri, 05 Apr 2024 17:42:49 -0400 X-MC-Unique: 0CdprE60Nai2xXCuJFAl1w-1 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-78d438954abso37597285a.1 for ; Fri, 05 Apr 2024 14:42:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712353369; x=1712958169; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Nh8AZu/36vuzSfX/Je7NxWoNvpcer/hOQkOAQFaqnk4=; b=tbPJdHrn9jDoQcen2m2LW/02wWsQ1gu1VpRy+iWNN5J389PjEdMR4El40EWPRtuoQa CDyWxi46TyBIzrUflU0Lx2Vz9uElRQATqZS/8L4AUmqUqwaPkBawiS+zebUUextjCw9G ICHlmS1a4+Bq2P1ZraK2LFzHxDyWOAYYXSuykC9QSZIpTpbdSekJmzXLhC6p3tADqkpP vyMaeUOCU9O8mOPGRebAtF4SaTnD3HR0rq36NeQy9/1VkuC+96XkLE/C1i8+38VKWE79 7slJ37Psn2/NH4jRaMHueqpJGj91FHc7HwZEyPuy3zBJuFzED1gRTo5k5dNKfs5P8nac Yl2g== X-Gm-Message-State: AOJu0Yy7umlq8vV7yvDuuoME5v46yWPc/pmFIldpuTRvFjs6ogTewzuZ 83F4BrcmUrb0I5u01kjbiXeyvBdwlrOejKj8cicsJ1OB7/iH/EUV9Obb0+JX3ZXDJl1O/ygPO2a VIAt2+5sw7GgLKl08CYJUgkfDmF6/UkdB0rtDFzRqMg9b8tTf X-Received: by 2002:a05:620a:24cb:b0:78b:ead0:4e98 with SMTP id m11-20020a05620a24cb00b0078bead04e98mr2827308qkn.5.1712353368781; Fri, 05 Apr 2024 14:42:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFYTCLlC89IJBPyweOipCCmgbTuVze3tgI8H3RxcclvMtkthTW+/IyM+0zA0bT9pfKklVWVNA== X-Received: by 2002:a05:620a:24cb:b0:78b:ead0:4e98 with SMTP id m11-20020a05620a24cb00b0078bead04e98mr2827279qkn.5.1712353368024; Fri, 05 Apr 2024 14:42:48 -0700 (PDT) Received: from x1n ([99.254.121.117]) by smtp.gmail.com with ESMTPSA id bl40-20020a05620a1aa800b00789e8405843sm971843qkb.32.2024.04.05.14.42.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Apr 2024 14:42:47 -0700 (PDT) Date: Fri, 5 Apr 2024 17:42:44 -0400 From: Peter Xu To: Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Michael Ellerman , Christophe Leroy , Matthew Wilcox , Rik van Riel , Lorenzo Stoakes , Axel Rasmussen , Yang Shi , John Hubbard , linux-arm-kernel@lists.infradead.org, "Kirill A . Shutemov" , Andrew Jones , Vlastimil Babka , Mike Rapoport , Andrew Morton , Muchun Song , Christoph Hellwig , linux-riscv@lists.infradead.org, James Houghton , David Hildenbrand , Andrea Arcangeli , "Aneesh Kumar K . V" , Mike Kravetz Subject: Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2 Message-ID: References: <20240321220802.679544-1-peterx@redhat.com> <20240322161000.GJ159172@nvidia.com> <20240326140252.GH6245@nvidia.com> <20240405181633.GH5383@nvidia.com> MIME-Version: 1.0 In-Reply-To: <20240405181633.GH5383@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 5DD72120022 X-Rspam-User: X-Stat-Signature: 1ofpjcztfaycbjnxu3sdm77jaoay37r5 X-Rspamd-Server: rspam01 X-HE-Tag: 1712353373-184563 X-HE-Meta: U2FsdGVkX18VInaQIkFhCzS9DEtIUowg2JNHnBVeAPVPCRVvrBGOq8J6uOp2uLDhgvio8JPBnp3GC90scXtjL57WZjmmQvJB9zkN4jgkRNqVUCZOIlvqd2rsZmUY1J4CpHohRMYpRMRFhxYvogwAY8JqWX+dhOjZ0ceMCQFOoSDGeUplkjf3qzdFxGE8mBt0AJLPTIuPdS2Zy3rNACpe+w1lFwTP2FzKFq9etYE8OoZdcCNubRzPepVveYPnxRXFigMpbT3CqylnmK0APRfJQtub7Qhd9ccuROSPJMxMZtW1weLn+jwEC5yHoLSeS7sUB001G5jqfM5y+LL5HFCde/y6CUdifwvFdKmrZ3Vf+juz/O247Ztsjcky+u7y7l2sdqhcIBmceiIfh50sMp6f3sFJd5ulmfdA2LCUH+EU0GBEktDV1X4Uh+tPTASvYBH0ASSp7C3/8RmElKd6wpjPkd6j20TxJrWI13oVc0zGF3exXOLU+6ssmfEmFwYpo6ogr4GSi2pBEqk9BF35xDLu2YCFpsWoTyrLozQeCt+s+Mgp2vWsNJY2EgKl9i9tTbRawTYKx0QIJuQz7h13XDJb2lYdLtSLT2wuBG+ZzOHSNBSHKUHfVZZeCETfsq/+x/yOhlLjl1DdTNDjS4ZdkoKkyuPwS0gWPU/gOQLwOyAlgjBb9yTXSAdfwsoSY3yYloisan69Wcp0pgWVsuxHZnw+EVUnZUEpf9o1G7drKUHXF5mwdmcS5IPKpn8qGh8iaQUqBIumCk/efF/hw+FZlYR/aBSDIVbk3fp+rKYwkg2MF8Kl543HRKusYVjKXToMnyGl/QE/SXDszxzKyv12reO01jUYeLwDmS+4f4amBhg1Sjf0O0OgMmdIGlcTNEshz3lHaY0tWGtzDfcwJffV/wQYDoOAUvMwIS7PBCD+JontShir45i+a+BUblhhl8hVdy+1+KdOLzd7ke5/c4G5/pE MuNLuFYz 2s97HXqcFKJ/jJCjoC6gQC1UBJC8UKANoMZCu2alxwpszP8QuDBfSdeewAqTap9qriL2gACBoIOoRUOhsrFMGcvIkqjDpPkGrLQPaFQ7bXcMoFIPi5iyhQYMchxSbvXzS7kguk5DrI4ypb+NsNgdwqX0/yt+ujiQg02x+IaSi9wbfNQ9t3dif1pRBoprRDKxDzFEMYe2Ou2i+/KiSPpetquQsQw+zbYDcLjZmVgAxNRVSV/ZHcQmyRpFTbpyt8qp9CuRVWwNaZJY7dTeKj022tD4toz+1Mg2YcgyLeZg7Z2uimDuYQj3pMehEkycf+8JesqmDeOFaAuWn5Gv8r0ZzNM8WKBeCcqppd+Yief4jh1AMKi718B2311TPQw== 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 Fri, Apr 05, 2024 at 03:16:33PM -0300, Jason Gunthorpe wrote: > On Thu, Apr 04, 2024 at 05:48:03PM -0400, Peter Xu wrote: > > On Tue, Mar 26, 2024 at 11:02:52AM -0300, Jason Gunthorpe wrote: > > > The more I look at this the more I think we need to get to Matthew's > > > idea of having some kind of generic page table API that is not tightly > > > tied to level. Replacing the hugetlb trick of 'everything is a PTE' > > > with 5 special cases in every place seems just horrible. > > > > > > struct mm_walk_ops { > > > int (*leaf_entry)(struct mm_walk_state *state, struct mm_walk *walk); > > > } > > > > > > And many cases really want something like: > > > struct mm_walk_state state; > > > > > > if (!mm_walk_seek_leaf(state, mm, address)) > > > goto no_present > > > if (mm_walk_is_write(state)) .. > > > > > > And detailed walking: > > > for_each_pt_leaf(state, mm, address) { > > > if (mm_walk_is_write(state)) .. > > > } > > > > > > Replacing it with a mm_walk_state that retains the level or otherwise > > > to allow decoding any entry composes a lot better. Forced Loop > > > unrolling can get back to the current code gen in alot of places. > > > > > > It also makes the power stuff a bit nicer as the mm_walk_state could > > > automatically retain back pointers to the higher levels in the state > > > struct too... > > > > > > The puzzle is how to do it and still get reasonable efficient codegen, > > > many operations are going to end up switching on some state->level to > > > know how to decode the entry. > > > > These discussions are definitely constructive, thanks Jason. Very helpful. > > > > I thought about this last week but got interrupted. It does make sense to > > me; it looks pretty generic and it is flexible enough as a top design. At > > least that's what I thought. > > Yeah, exactly.. > > > However now when I rethink about it, and look more into the code when I got > > the chance, it turns out this will be a major rewrite of mostly every > > walkers.. > > Indeed, it is why it may not be reasonable. > > > Consider that what we (or.. I) want to teach the pXd layers are two things > > right now: (1) hugetlb mappings (2) MMIO (PFN) mappings. That mostly > > shares the generic concept when working on the mm walkers no matter which > > way to go, just different treatment on different type of mem. (2) is on > > top of current code and new stuff, while (1) is a refactoring to drop > > hugetlb_entry() hook point as the goal. > > Right, I view this as a two pronged attack > > One one front you teach the generic pXX_* macros to process huge pages > and push that around to the performance walkers like GUP > > On another front you want to replace use of the hugepte with the new > walkers. > > The challenge with the hugepte code is that it is all structured to > assume one API that works at all levels and that may be a hard fit to > replace with pXX_* functions. That's the core of problem, or otherwise I feel like I might be doing something else already. I had a feeling even if it's currently efficient for hugetlb, we'll drop that sooner or later. The issue is at least hugetlb pgtable format is exactly the same as the rest, as large folio grows it will reach the point that we complain more than before on having hugetlb does its smart things on its own. > > The places that are easy to switch from hugetlb to pXX_* may as well > do so. > > Other places maybe need a hugetlb replacement that has a similar > abstraction level of pointing to any page table level. IMHO this depends. Per my current knowledge, hugetlb is only special in three forms: - huge mapping (well, this isn't that special..) - cont pte/pmd/... - hugepd The most fancy one is actually hugepd.. but I plan to put that temporarily aside - I haven't look at Christophe's series yet, however I think we're going to solve orthogonal issues but his work will definitely help me on reaching mine, and I want to think through first on my end of things to know a plan. If hugepd has its chance to be generalized, the worst case is I'll leverage CONFIG_ARCH_HAS_HUGEPD and only keep hugetlb_entry() for them until hugepd became some cont-pxx variance. Then when I put HAS_HUGEPD aside, I don't think it's very complicated, perhaps? In short, hugetlb mappings shouldn't be special comparing to other huge pXd and large folio (cont-pXd) mappings for most of the walkers in my mind, if not all. I need to look at all the walkers and there can be some tricky ones, but I believe that applies in general. It's actually similar to what I did with slow gup here. Like this series, for cont-pXd we'll need multiple walks comparing to before (when with hugetlb_entry()), but for that part I'll provide some performance tests too, and we also have a fallback plan, which is to detect cont-pXd existance, which will also work for large folios. > > I think if you do the easy places for pXX conversion you will have a > good idea about what is needed for the hard places. Here IMHO we don't need to understand "what is the size of this hugetlb vma", or "which level of pgtable does this hugetlb vma pages locate", because we may not need that, e.g., when we only want to collect some smaps statistics. "whether it's hugetlb" may matter, though. E.g. in the mm walker we see a huge pmd, it can be a thp, it can be a hugetlb (when hugetlb_entry removed), we may need extra check later to put things into the right bucket, but for the walker itself it doesn't necessarily need hugetlb_entry(). > > > Now the important question I'm asking myself is: do we really need huge p4d > > or even bigger? > > Do we need huge p4d support with folios? Probably not.. > > huge p4d support for pfnmap, eg in VFIO. Yes I think that is possibly > interesting - but I wouldn't ask anyone to do the work :) Considering it does not yet exist, and we don't have plan to work it out (so far), maybe I can see this as a very implicit ack that I can put that aside at least of now. :) > > But then again we come back to power and its big list of page sizes > and variety :( Looks like some there have huge sizes at the pgd level > at least. Yeah this is something I want to be super clear, because I may miss something: we don't have real pgd pages, right? Powerpc doesn't even define p4d_leaf(), AFAICT. $ git grep p4d_leaf arch/powerpc/mm/book3s64/radix_pgtable.c: if (p4d_leaf(*p4d)) { arch/powerpc/mm/pgtable.c: if (p4d_leaf(p4d)) { arch/powerpc/mm/pgtable_64.c: if (p4d_leaf(p4d)) { arch/powerpc/mm/pgtable_64.c: VM_WARN_ON(!p4d_leaf(p4d)); arch/powerpc/xmon/xmon.c: if (p4d_leaf(*p4dp)) { They all constantly return false (which is the fallback)? > > > So, can we over-engineer too much if we go the generic route now? > > Yes we can, and it will probably be slow as well. The pXX macros are > the most efficient if code can be adapted to use them. > > > Considering that we already have most of pmd/pud entries around in the mm > > walker ops. > > Yeah, so you add pgd and maybe p4d and then we can don't need any > generic thing. If it is easy it would be nice. I want to double check on above on PowerPC first, otherwise I'd consider leaving p4d+ alone, if that looks ok. It could be that I missed something important, Christophe may want to chim in if he has any thoughts or just to clarify my mistakes. Thanks, -- Peter Xu