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 841E4C47DD9 for ; Sat, 23 Mar 2024 02:15:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 176306B0087; Fri, 22 Mar 2024 22:15:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 124EF6B0089; Fri, 22 Mar 2024 22:15:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2E7D6B008A; Fri, 22 Mar 2024 22:15:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E59956B0087 for ; Fri, 22 Mar 2024 22:15:32 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B9CF9A16CD for ; Sat, 23 Mar 2024 02:15:32 +0000 (UTC) X-FDA: 81926687304.07.69964E4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 87C0D80005 for ; Sat, 23 Mar 2024 02:15:30 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E2onWG02; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711160130; 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=pAkp5p3e769nx5gm8jMLR0gRsGSeiOkGgQjUssudat0=; b=3cspFto0pjfEP8b4YkMxYadBAe4ivv4mnv6HgMPh/QHbMGiDTi5Ger/VRderg0tYeyya4D +6P55BA37HcsRIUelH3ZF/KsLM+5foS/Jyi/DFKTWGImu/DiBRqN1t/+BcVM5nooIF1oeW GztY32Yc7X6PM64x8CzVeZFyCNjeJ2U= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E2onWG02; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711160130; a=rsa-sha256; cv=none; b=Xj9BH6++B1/XbxtDFc1P87Ur/vYyvr1VLqEToEz1iH093M/a4Z7OjcmCZF+qpKVufp0+PE uS4MPkZ6RCVheoui6HWneYfJhbNBsSqVs0nQs8SSv7N3xjfIuTO53ANJ+Td+qji++mv1Pv w9do9S0QNN59ps8yMNuQrd8RU6fvfkc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711160129; 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=pAkp5p3e769nx5gm8jMLR0gRsGSeiOkGgQjUssudat0=; b=E2onWG02mtI9NWZ539rc+FGL3e+FzxxUNlhpw0EB41GoQGXRYlrAuAJ48alY3d0dODV9cm XYBNlBKgyC7erd3RkV3FJMmI84cQ5+Dls+w3QBGOCwr+/rI/JJPIPVUxWKt7CVV5NqxntU OfmzaoO7LZkXzkC5kV5g7bJLwIA8ItA= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-568-bB-BVs7INU-eYeqPD0bjcA-1; Fri, 22 Mar 2024 22:15:28 -0400 X-MC-Unique: bB-BVs7INU-eYeqPD0bjcA-1 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-430c9bbe925so5082381cf.0 for ; Fri, 22 Mar 2024 19:15:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711160124; x=1711764924; 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=pAkp5p3e769nx5gm8jMLR0gRsGSeiOkGgQjUssudat0=; b=Vf8FTUmPgebiUpc2/HMYh9d5AgCYhwBPwTHjH4LW3+Ku84tW7wVHN8IKQMUjjlz42+ TLRtnLsCUsEa9uZC1xIdatfiKwRJAhi0ZYe7oG5+GreODhOJL6bj6P3VfZoswR6FRhgP BFIC4dEKeYB8SRi/VzrwDnYiwOaxFtmJTkQvh4DnZDGpys9Pj7Ou9FuZ4AU3O0jfEMHB WJ1JpDFWk9ly+ITzSQJoSgARdAsE82crl2ydlCNac72gKptZXQSKmeanoFJlaBib0waj HNhoUN+1WVmmi/YilAR6PZcKaIt+qwRZe7XisR0DV4SuZV/eJJNkl0F7dqKVFCOCMm5w SOzw== X-Gm-Message-State: AOJu0YxIr9u6c3I6EH9xuyNSo7jH3SRz+OhLiUfQ5/c7Is7oOPtbuA0a 8HFYGJMEfgxszgZ6+HOJEAe4WkSQ/iyWu4EMGGvXfyd7NBKi/WCcJbqEkZaLr1bo+FCBjzBDCor 8n9bIHQ7ceWyOFauqhP4GHGUhHBH3aFIwIdcPKDBV2bYVNU2x X-Received: by 2002:a05:622a:528b:b0:431:3e97:fb0b with SMTP id dr11-20020a05622a528b00b004313e97fb0bmr799013qtb.3.1711160124131; Fri, 22 Mar 2024 19:15:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGSSiaxwf9qVJ61bWD658BkK6bIoISbqMAPHSz2R/uod8u0yF1+dnf1k4ZlNnixmtjYf7I/qg== X-Received: by 2002:a05:622a:528b:b0:431:3e97:fb0b with SMTP id dr11-20020a05622a528b00b004313e97fb0bmr798965qtb.3.1711160123562; Fri, 22 Mar 2024 19:15:23 -0700 (PDT) Received: from x1n ([99.254.121.117]) by smtp.gmail.com with ESMTPSA id f9-20020a05622a114900b0043140cd9996sm152221qty.38.2024.03.22.19.15.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 19:15:23 -0700 (PDT) Date: Fri, 22 Mar 2024 22:15:20 -0400 From: Peter Xu To: Andrew Morton 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 , Muchun Song , Christoph Hellwig , linux-riscv@lists.infradead.org, James Houghton , David Hildenbrand , Jason Gunthorpe , Andrea Arcangeli , "Aneesh Kumar K . V" , Mike Kravetz Subject: Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code Message-ID: References: <20240321220802.679544-1-peterx@redhat.com> <20240321220802.679544-13-peterx@redhat.com> <20240322134818.9b312f77629f79fcf1564b6f@linux-foundation.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 87C0D80005 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: sr4dttipsd4naa1ioem8337zbnmi7nqg X-HE-Tag: 1711160130-308762 X-HE-Meta: U2FsdGVkX1/FJS/92d8ysWnIPvb4L0MkpBsji6pHrbZTpX4E8Ytw4n/8bIwb4Bw5sIWg24aWTP4/nZyLIzPEIPSeECKzGmYUQhZI+cnHaOVAf3wWeMZz476fzVFdCIuUPwWwBTkULuPsy4X5a6hmlwN/dmNbTXtAyihU5zCsa2m6vId+QhBdvy9/NtabsEgf3guvjQc2Qkh3rTxVUI6686CGZkkl8No02FMozXshhXak1mGPJEELolVlb+gUs3kbQwO5HdIP9axJaZm4kn/+taH4RXt/tTWjjY6cko9OCp409kOEPBDygTFlweCEAoKofuoS8zS6GAL3YEY1vQcgJZ/YNFG2DGre54m3IXxpShx1zV17qaox26Se6VBFVM9Lg30INroYajrv7xxfCLWEy1JmZS1kiPazYwyUGBMNAFIKBLaKgsBPWkE/QX3T7cwt1XIp83HC9sQrVY6g+K1/B/vfvdqrMXHXL6CGEKp5yQGlxekHatO1rKf/nll6xL1xV5SpjDTzQ3AXtXSgYWig0gQfF0esnwN0POF0G7/Ki1ASuTucY7+M3eWttT4fN7BjO8OST+0bVcYoeWxXc939oXJ9McrvZtcawQFPAIY7LryoQrT6VNkKDhhFP4/H2m1dDSGM/8zD5Opz/Q83BUKPZBOEfAbrL8bz2AhiYHZyoWe9XhjyOe3BW1lfCVoZvDRvgjsI2c0qp2SwMukGFtmO7yK+YqZaiPv/hmkLd4+TWPLBShiv6OgYPJwcSkKO5H0yFP+oud5h5Blb7Ecj0Ra0qw1yLOvQKY+JSzJ3ZAALR6lCIjVPX9tDikjnTK+b4oFIAf7PcLEJl+GqsFn/ZK3pu/uzbzaBnIp1glzJrxcVoHskWANbogG92giBwy2iUOJLfVt7gN86cZu0xDA5YpWmfJMjkEPz+K1BTJjCXnTfRz9FvTjaNKxco5+5RBpN/Z+6LVGUiFYa2DMETUs7uw2 lJTwRilo pd0PTTaM/O5woQjPgpVZ7/TnGTT5yrjR022lMyjsa7yjrLDCMk9p8ncA+3wOr6+XXVX2uHWRPA/4q4r89vLh0poowJXtl7ipcishv6EhDTobx5aBUjo+HWK4X6fx/OEEND9mAhUXirjb3/xLks8/aF5LmvC1hNUicbYTQRwAqOUIq3NTd5PsEuOgQoToVqt0f6kjkMOveXZPBCCCutU+m8OPlN+u3rrEiVXW0ZqW4JQg1ewzEOelDn2GyOya8DiB3Nb+0Ejn9MtQ9xD1znnI+TVpfAso6+Y772iLQHXUuwHwChP0e+DL3sw8N7BrWZv+BB+T7iTfQHtDSoYFNutRa7GPfsrk1pKsbrOLxiSj+G1YNLtC+eKdco6JEgAZ7F/uNMZz49CxuaZ9fHnQ2WE0jO3mjyxlun+WAQpt2rk6MqLy4JzHoplFzp19TfA== 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, Mar 22, 2024 at 08:45:59PM -0400, Peter Xu wrote: > On Fri, Mar 22, 2024 at 01:48:18PM -0700, Andrew Morton wrote: > > On Thu, 21 Mar 2024 18:08:02 -0400 peterx@redhat.com wrote: > > > > > From: Peter Xu > > > > > > Now follow_page() is ready to handle hugetlb pages in whatever form, and > > > over all architectures. Switch to the generic code path. > > > > > > Time to retire hugetlb_follow_page_mask(), following the previous > > > retirement of follow_hugetlb_page() in 4849807114b8. > > > > > > There may be a slight difference of how the loops run when processing slow > > > GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each > > > loop of __get_user_pages() will resolve one pgtable entry with the patch > > > applied, rather than relying on the size of hugetlb hstate, the latter may > > > cover multiple entries in one loop. > > > > > > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over > > > a tight loop of slow gup after the path switched. That shouldn't be a > > > problem because slow-gup should not be a hot path for GUP in general: when > > > page is commonly present, fast-gup will already succeed, while when the > > > page is indeed missing and require a follow up page fault, the slow gup > > > degrade will probably buried in the fault paths anyway. It also explains > > > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup: > > > accelerate thp gup even for "pages != NULL"") lands, the latter not part of > > > a performance analysis but a side benefit. If the performance will be a > > > concern, we can consider handle CONT_PTE in follow_page(). > > > > > > Before that is justified to be necessary, keep everything clean and simple. > > > > > > > mm/gup.c:33:21: warning: 'follow_hugepd' declared 'static' but never defined [-Wunused-function] > > 33 | static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd, > > | ^~~~~~~~~~~~~ > > > > --- a/mm/gup.c~mm-gup-handle-hugepd-for-follow_page-fix > > +++ a/mm/gup.c > > @@ -30,10 +30,12 @@ struct follow_page_context { > > unsigned int page_mask; > > }; > > > > +#ifdef CONFIG_HAVE_FAST_GUP > > static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd, > > unsigned long addr, unsigned int pdshift, > > unsigned int flags, > > struct follow_page_context *ctx); > > +#endif > > > > static inline void sanity_check_pinned_pages(struct page **pages, > > unsigned long npages) > > _ > > > > > > This looks inelegant. > > > > That's two build issues so far. Please be more expansive in the > > Kconfig variations when testing. Especially when mucking with pgtable > > macros. > > Andrew, > > Apologies for that, and also for a slightly late response. Yeah it's time > I'll need my set of things to do serious build tests, and I'll at least > start to cover a few error prone configs/archs in with that. > > I was trying to rely on the build bot in many of previous such cases, as > that was quite useful to me to cover many build issues without investing my > own test setups, but I think for some reason it retired and stopped working > for a while. Maybe I shouldn't have relied on it at all. > > For this specific issue, I'm not sure if CONFIG_HAVE_FAST_GUP is proper? > As follow_hugepd() is used in slow gup not fast. So maybe we can put that > under CONFIG_MMU below that code (and I think we can drop "static" too as I > don't think it's anything useful). My version of fixup attached at the end the static is useful; below patch did pass on m68k but won't on x86.. ignore that please. > of email, and I verified it on m68k build. > > I do plan to post a small fixup series to fix these issues (so far it may > contain 1 formal patch to touch up vmstat_item_print_in_thp, and 2 fixups > where I'll mark the subject with "fixup!" properly). Either you can pick > up below or you can wait for my small patchset, should be there either > today or tomorrow. I changed plan here too; I found more users of HPAGE_PMD_NR assuming it's defined even if !CONFIG_MMU. That's weird, as CONFIG_MMU doesn't even define PMD_SHIFT... To fix this I decided to use the old trick on using BUILD_BUG() like it used to work before; frankly I don't know how that didn't throw warnings, but i'll make sure it passes all known builds (ps: I still haven't got my build harness ready, so that will still be limited but should solve known issues). In short: please wait for my fixup series. Thanks. > > Thanks, > > ===8<=== > diff --git a/mm/gup.c b/mm/gup.c > index 4cd349390477..a2ed8203495a 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -30,11 +30,6 @@ struct follow_page_context { > unsigned int page_mask; > }; > > -static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd, > - unsigned long addr, unsigned int pdshift, > - unsigned int flags, > - struct follow_page_context *ctx); > - > static inline void sanity_check_pinned_pages(struct page **pages, > unsigned long npages) > { > @@ -505,6 +500,12 @@ static inline void mm_set_has_pinned_flag(unsigned long *mm_flags) > } > > #ifdef CONFIG_MMU > + > +struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd, > + unsigned long addr, unsigned int pdshift, > + unsigned int flags, > + struct follow_page_context *ctx); > + > static struct page *no_page_table(struct vm_area_struct *vma, > unsigned int flags, unsigned long address) > { > ===8<=== > > -- > Peter Xu -- Peter Xu