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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F9E9C5AD4C for ; Thu, 23 Nov 2023 15:48:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346178AbjKWPrx (ORCPT ); Thu, 23 Nov 2023 10:47:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346072AbjKWPrv (ORCPT ); Thu, 23 Nov 2023 10:47:51 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CCA0DC1 for ; Thu, 23 Nov 2023 07:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vasH22+ZqE7NawyIR92P5uPhDSRcq1ysNxbjToJ1LBY=; b=vLpbgGizfUkL6qUgpsivl4JAm/ l8J8tNyrQHt5ij+7+mH22jvJHwKDnm15G+Y8yMTDvxK5gRlnADcaWJ0gGwXnEL+X6/fGctU+gIkgH i7e0bTPjn5mArHPGmVnZ3Sd4irNBwcAJX3hcvaGLJPXbWqYn15n3uPyDZxtwkLGiuzrZBSL0W3h7g 0NnaVmbnZK083gVv5tpkKKqa2NiGaBEqg1aGsZitgcpovI9OR2AvH5HpmcbdwkXTFME1UrDr2MgzP GZEnBpDtPaOAgDKKUAZp8G4YTEUeZWMFnI74HVPypN/duW75NVuUCoPbRlM89yKGH7bN101Tg5qlt qowOlYxw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r6Bvh-007gJ1-SR; Thu, 23 Nov 2023 15:47:49 +0000 Date: Thu, 23 Nov 2023 15:47:49 +0000 From: Matthew Wilcox To: Christoph Hellwig Cc: Peter Xu , 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 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 22, 2023 at 12:00:24AM -0800, Christoph Hellwig wrote: > > 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. It looks like ARM (in the person of Ryan) are going to add support for something equivalent to hugepd. Insofar as I understand hugepd, anyway. I've done my best to set up the generic code so that the arch code can use whatever size TLB entries it supports. I haven't been looking to the hugetlb code as a reference for it, since it can assume natural alignment and generic THP/large folio must be able to handle arbitrary alignment. If powerpc want to join in on the fun, they're more than welcome, but I get the feeling that investment in Linux-on-PPC is somewhat smaller than Linux-on-ARM these days. Even if we restrict that to the server space.