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 6A247C61D99 for ; Wed, 22 Nov 2023 15:22:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E70ED8D0034; Wed, 22 Nov 2023 10:22:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E20F48D0008; Wed, 22 Nov 2023 10:22:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE9F28D0034; Wed, 22 Nov 2023 10:22:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BDB258D0008 for ; Wed, 22 Nov 2023 10:22:25 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9118DA0D84 for ; Wed, 22 Nov 2023 15:22:25 +0000 (UTC) X-FDA: 81485956650.28.52ECEF1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 734EA1C000D for ; Wed, 22 Nov 2023 15:22:22 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=L+FMgC5A; spf=pass (imf20.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.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=1700666542; a=rsa-sha256; cv=none; b=EbMZYbE5lHZBBUkBiBVkMw5gyAkHHYY4nHVjy6IKIdEwongNUVV98AA0M71m2Z9lPANEJZ gk67Ek1F3bZoGv7bckrL7RuhP1PWC8i+efL19eSZLHpDLkBZhHJCToGRlvK3kGRswC+BrX 4UeMmsuGegpfHRmEao1stXvLy3Mqrtw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=L+FMgC5A; spf=pass (imf20.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.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=1700666542; 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=jHf7jc7J8Bv83RTgjktPDmyDKiNjMVCeKkEQ7LZmkKc=; b=zkqp+J52UkcVBjRQbqKpIHvO3oo+Nzxxj2QEUREQW3Ac/zCfpATpY2UIt1kflp4ir6FEg4 uwp5lgb99muW9Qw07B0fluCWvk9iY5kEbabAzmqffbmoNoTUXrtPseQveM63vT7k8FGr5w 6zSDFx+GqG+PTzQ9n5oo8MYEwgEPugo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700666541; 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=jHf7jc7J8Bv83RTgjktPDmyDKiNjMVCeKkEQ7LZmkKc=; b=L+FMgC5Aaw9pf6L3o+76/eGauNJCl1mBqgp/3goyXUkLA8WIs5QS2WX1ARi5N0qVR8BGc1 jrP9WlAIOC7L4JakJ9GBnfJgL7FwyMd6LIxHT1zEX2xKv3HjgGD25cz/iiId8Aepxp37BW uNQcSgCKWOwQqM7D5B0jvm+BAEBdLb4= Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-463-Ieqz9U66NbGh-JUi2ADqHQ-1; Wed, 22 Nov 2023 10:22:20 -0500 X-MC-Unique: Ieqz9U66NbGh-JUi2ADqHQ-1 Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-58d07f8a92bso63882eaf.0 for ; Wed, 22 Nov 2023 07:22:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700666540; x=1701271340; 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=jHf7jc7J8Bv83RTgjktPDmyDKiNjMVCeKkEQ7LZmkKc=; b=JFKU0o2nZ9ebsUq8nRtIKVTzz8UtMn2L9c/ixVck1uDjQazfeGVlHvwNMEG4gMLuLi Ma1tb7zyORR0Nuvs3uLqe5xS0Sn8SciSt3T+PQCPWC1nua4jUi9qBr581YmivYg6w1ZW b/r/fEq4eyViE9zP4X18q3IzSLfu68gaOi/VIFVS705zPqZJ1q1dyOMrdmWmsDcLca84 sII7L0LfaWr4+VvUFLJ1AEhPYq5tVjkk8NYbAas1wV7EQ7/XWSXBRW7pJy4lNvQ8E7V0 Y2QoxVw5pkHHpH+H6AQzckGtjhWBucGQU8pGly2e8YxMpMq7jrsxfpHow/zDNDP0q/4Z J4yw== X-Gm-Message-State: AOJu0YylxrMkArLHGigciOQ2sZ1pdzOiBtx1OVAKga1t1SRB7idhlkI4 m9enXHwsAIuD+A3nhD1aIL6vsHbo7o0MlyMhLrukwzRBVn6h09XNs/wkpseH5rpUUk3pZkbmyLS MAj718n7v+co= X-Received: by 2002:a05:6820:311:b0:58c:e80a:537d with SMTP id l17-20020a056820031100b0058ce80a537dmr3009142ooe.1.1700666539802; Wed, 22 Nov 2023 07:22:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IHOaFlUlKMrMvbpX5vlLOYOyqCZqIYmeCKyEeM2CWjyOcsp+BCB1xOxZFIWf6oSiyQQHcWwQQ== X-Received: by 2002:a05:6820:311:b0:58c:e80a:537d with SMTP id l17-20020a056820031100b0058ce80a537dmr3009114ooe.1.1700666539416; Wed, 22 Nov 2023 07:22:19 -0800 (PST) Received: from x1n (cpe688f2e2cb7c3-cm688f2e2cb7c0.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id m13-20020a0cbf0d000000b0066d04196c3dsm4941000qvi.49.2023.11.22.07.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Nov 2023 07:22:18 -0800 (PST) Date: Wed, 22 Nov 2023 10:22:11 -0500 From: Peter Xu To: Christoph Hellwig Cc: 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 , Matthew Wilcox , Jason Gunthorpe , Axel Rasmussen , "Kirill A . Shutemov" , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Mike Rapoport , Mike Kravetz Subject: Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing Message-ID: References: <20231116012908.392077-1-peterx@redhat.com> <20231116012908.392077-7-peterx@redhat.com> 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-Server: rspam08 X-Rspamd-Queue-Id: 734EA1C000D X-Stat-Signature: f1fseoc99jxzimw1orhj34m9y8118gzt X-Rspam-User: X-HE-Tag: 1700666542-778518 X-HE-Meta: U2FsdGVkX19EO55PsXqQ59dMMmAvmJgrmkcZtVDJfRECHIfPex7u2D6fDz9kektirZKKbsmJI9Xvz+byUJCK7bqjwlgOaLWCHjOcmMzGrX9CXbhsQT1pm584Gi1vZ/jInQ7GEs5XdEXfamwLLw64JCkXgZ0XZUK2qXYzywB6cMZBj6GA6RPxfPbwGftkpTPdigpB/qLQMi9nmdUf0Vsk7AJepkWOQSXqYGbCqcEQ5gy7fE0T3eeWUCHyO3JdNFsV3z/pR2fbJDNqQa2DHA8XPMeqwwbeLZ4QrauGRf008/GnYATDNMfz4RaIP0dx9FxZAQWfIvZxUFyi7alzPRBrwVFbzx6o/3BHUw6NxN8V9ieRcxdnll7FEvpJe7j2Ik9iYcqtvj9jkdjQpbBXhIUMTHFiGrbHk8WiKGz9CS24hlQ8ejNLra9btRqqd7SX5w4o3nZVmUetGM2f0vRVQ2q/eLMweOygfAFJ8EXSZygeK17d0BDYgN1BtChAPKXKhTv4YHB77SZ700GzncaZmXW0I1b4uHc6/okYizKulqLB5T1UjZ8Z+ausrMqf8EIT6lUYEZ0WKA59D9nf/IC9+YhSCd+el7JarbBCKEtMS6z6WMkF/yG+YkYheLrcdHP6pkpVffNbo8r1zOCTYA8fMHBt5mNo410/T8WC1LEEFcaccNYj6VlQ31iMY4vJO26GfvGMGs+ShbVivnXuvLIklEI72jOmIIpw7csAIHBODc43GKaSLNV1fmXCe2JwbfKqPoEQvrzLwv5TDwYoxQ0CROir6TX9dowfg5AgDgkP86YEUkQ5JX3nEUd75GCgNBz1//rZ/jXUYNnJ3b7xXzGxqNggktU0zNbgXwcXqT7bfXdp8C79Tt9mNV+wotbE8CP1Vz6gqUJzoutTuOCaMkhiOL4czANPpNrIVJelUC118JLlunNnMbT6zNwkVPh9EP1ZPPxAO+iGqQRgKY/KHhcmogy ZvfMPqA2 GIDf8NphanEQkts/n8LZwfHnMeL/OtWTp/NSFi+0Bcu8nRv24r+iG3SyLHZo7XAtBYjaitZhkbvuC9bZYI3sW1VmchN5GrRt19PK1mKwU5e9kEQXZYQ6p9tvpEL1mqB60180TDRQn9xS10xG8QSzgHYvkFAstHkJpkOKY+0uyNy+QCr2NnW863D9KT2LoCOifdTs+A3IX4sMWmcOr3vlCl+i5GIZENrRAuVK63Op32NPKy+tzTNlRx4FOQZPuZMiinvhdtBw5cZL6Gz3lUvXEXqLgmNC6Cn+syQrVRFfPcbxiZs+MkbWxVGTSZ7I1z1Y0SJ3stWRpVROmCtVSD71lofygDWki2Ws5S0x0t5xHR7po+bUlWI+NQOgeb1JwQlui8A1f0bOTxlD0odXc7E+Zpd2w0t57Kdm3v8dz5if1YE3LfayOuXMD8z0iBQ3ZS0xLzZ9eSfuWMKO7DL8aAC7vcvJC9A== 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 Wed, Nov 22, 2023 at 12:00:24AM -0800, Christoph Hellwig wrote: > On Tue, Nov 21, 2023 at 10:59:35AM -0500, Peter Xu wrote: > > > What prevents us from ever using hugepd with file mappings? I think > > > it would naturally fit in with how large folios for the pagecache work. > > > > > > So keeping this check and generalizing it seems like the better idea to > > > me. > > > > But then it means we're still keeping that dead code for fast-gup even if > > we know that fact.. Or do we have a plan to add that support very soon, so > > this code will be destined to add back? > > The question wasn't mean retorical - we support arbitrary power of two > sized folios for the pagepage, what prevents us from using hugepd with > them right now? Ah, didn't catch that point previously. Hugepd is just not used outside hugetlb right now, afaiu. For example, __hugepte_alloc() (and that's the only one calls hugepd_populate()) should be the function to allocate a hugepd (ppc only), and it's only called in huge_pte_alloc(), which is part of the current arch-specific hugetlb api. And generic mm paths don't normally have hugepd handling, afaics. For example, page_vma_mapped_walk() doesn't handle hugepd at all unless in hugetlb specific path. There're actually (only) two generic mm paths that can handle hugepd, namely: - fast-gup - walk_page_*() apis (aka, __walk_page_range()) For fast-gup I think the hugepd code is in use, however for walk_page_* apis hugepd code shouldn't be reached iiuc as we have the hugetlb specific handling (walk_hugetlb_range()), so anything within walk_pgd_range() to hit a hugepd can be dead code to me (but note that this "dead code" is good stuff to me, if one would like to merge hugetlb instead into generic mm). This series tries to add slow gup into that list too, so the 3rd one to support it. I plan to look more into this area (e.g., __walk_page_range() can be another good candidate soon). I'm not sure whether we should teach the whole mm to understand hugepd yet, but slow gup and __walk_page_range() does look like good candidates to already remove the hugetlb specific code paths - slow-gup has average ~add/~del LOCs (which this series does), and __walk_page_range() can remove some code logically, no harm I yet see. Indeed above are based on only my code observations, so I'll be more than happy to be corrected otherwise, as early as possible. > > > The other option is I can always add a comment above gup_huge_pd() > > explaining this special bit, so that when someone is adding hugepd support > > to file large folios we'll hopefully not forget it? But then that > > generalization work will only happen when the code will be needed. > > If dropping the check is the right thing for now (and I think the ppc > maintainers and willy as the large folio guy might have a more useful > opinions than I do), leaving a comment in would be very useful. Willy is in the loop, and I just notice I didn't really copy ppc list, even I planned to.. I am adding the list (linuxppc-dev@lists.ozlabs.org) into this reply. I'll remember to do so as long as there's a new version. The other reason I feel like hugepd may or may not be further developed for new features like large folio is that I saw Power9 started to shift to radix pgtables, and afaics hugepd is only supported in hash tables (hugepd_ok()). But again, I confess I know nothing about Power at all. Thanks, -- Peter Xu