Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1726360pxb; Wed, 20 Oct 2021 10:30:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwnj4e7MDM87ViwZb91+v7gbIN2o3tZ4oSWpYhVqTCg88pAsAabpKQJI1XI02d9cxe0LVtm X-Received: by 2002:a05:6a00:1488:b0:44d:25b2:f80b with SMTP id v8-20020a056a00148800b0044d25b2f80bmr649933pfu.20.1634751040111; Wed, 20 Oct 2021 10:30:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634751040; cv=none; d=google.com; s=arc-20160816; b=fiTk0w12mn8WXAwy/QcL0XgBvazIi9HSyf9JRJIHl6pKR6myFhQ5xBFCsdXZ9UiDcX HAU3xLsFBGEhPgF/eddVfsTRTTZpek1KNj0ydwi/flbWqt95wjw9NNbZvXXX9R3e1WLB dC7kL4OJ4vkC+tYmoYUFycTnP4j1zrJ8elQ+lJxN0NeEzK/6BtBene2yD7p71eA2sqE3 mklJ5xIQIFf/RpckqGdaZN7vKAJKIvnZ6BfNzp6DhKJPTNJlull2JT6A9pgeNhW3QYG8 LxeuZTNQPJ8TpNY/sfv9g5C23DPCOegVm1jrIfepyJyRiIiuT+3Lxl+0yEYLsJ21jTkV d/kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=2j0OkvRwF5BVDtZ9M6bIK+b+BCFxIxg1XmoiRh7ewBA=; b=qItK6adGMGO1STm4Ecrs3m/tYxBznDw8/rBJK7lGZx3vP1NB/U1Q5GbUTWW/gUcbtb 4nggslbzyEVhBPbw/mk4WFcFGGYMzAxHDD+9dsEPeONhoVHR8rP20so02noFSBWxtm3S T4QKuD0cSyOK5RS1CWI25TvIxZRwzu73r0olb8k0m16ShAK7thduPztd27SjCy9DIjOt E3ig48DF7YTAez7aslQpi01xkl0P6GpQijqoqCfJiBoDvygx7uxflpQ15EZEP9Rb6Ijg PmEpz0+9gbtzoMMxRiFlEwJ1/nQPWJ9V3DTrze1mF9eptXGwCiK96MWkYs8udX2wu4go Ic3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="ua/XQ9oU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k4si5063503plk.60.2021.10.20.10.30.26; Wed, 20 Oct 2021 10:30:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="ua/XQ9oU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229941AbhJTRbY (ORCPT + 99 others); Wed, 20 Oct 2021 13:31:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230196AbhJTRbY (ORCPT ); Wed, 20 Oct 2021 13:31:24 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6780AC06161C; Wed, 20 Oct 2021 10:29:09 -0700 (PDT) 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=2j0OkvRwF5BVDtZ9M6bIK+b+BCFxIxg1XmoiRh7ewBA=; b=ua/XQ9oU8XbbXQIXxSprskj1uQ gyN/V4q80GLHf6RXs3osc2ii3oplGC5gcj7/CNFCrbVc65tKzQ7lC5vRwnxBlVgfxZBC2Q7adlTqp 9k/YlzgpjoR2obS6HeHNz2F4osZIBhx3hlEo7g7aKMcD2q5GChO6O0z9hVsR+1LdEe5G+HIkUjCMZ 5d9twredgZVF2pwB5Rj9hprVgBUkTaCd8ZzMFSZENLmWD4UXBO8Nk0uVYqbpHq/Ro+cQLirvUQ9Ev /43jtLS1vXu0/ZVbxwsTup/iYlYCVK+QMi6+sN9zmQL2boAttS69mNgq3bfiiP8v1me3ZTv8mIG+r CRt2nnLQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mdFM6-00Cj4B-04; Wed, 20 Oct 2021 17:26:49 +0000 Date: Wed, 20 Oct 2021 18:26:21 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Johannes Weiner , "Kirill A. Shutemov" , Kent Overstreet , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells , Hugh Dickins Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap - Message-ID: References: <20211018231627.kqrnalsi74bgpoxu@box.shutemov.name> <996b3ac4-1536-2152-f947-aad6074b046a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <996b3ac4-1536-2152-f947-aad6074b046a@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 20, 2021 at 09:50:58AM +0200, David Hildenbrand wrote: > For the records: I was happy to see the slab refactoring, although I > raised some points regarding how to access properties that belong into > the "struct page". I thought the slab discussion was quite productive. Unfortunately, none of our six (!) slab maintainers had anything to say about it. So I think it's pointless to proceed unless one of them weighs in and says "I'd be interested in merging something along these lines once these problems are addressed". > As raised elsewhere, I'd also be more comfortable > seeing small incremental changes/cleanups that are consistent even > without having decided on an ultimate end-goal -- this includes folios. > I'd be happy to see file-backed THP gaining their own, dedicated type > first ("struct $whatever"), before generalizing it to folios. I am genuinely confused by this. Folios are non-tail pages. That's all. There's no "ultimate end-goal". It's just a new type that lets the compiler (and humans!) know that this isn't a tail page. Some people want to take this further, and split off special types from struct page. I think that's a great idea. I'm even willing to help. But there are all kinds of places in the kernel where we handle generic pages of almost any type, and so regardless of how much we end up splitting off from struct page, we're still going to want the concept of folio. I get that in some parts of the MM, we can just assume that any struct page is a non-tail page. But that's not the case in the filemap APIs; they're pretty much all defined to return the precise page which contains the specific byte. I think that's a mistake, and I'm working to fix it. But until it is all fixed [1], having a type which says "this is not a tail page" is, frankly, essential. [1] which is a gargantuan job because I'm not just dealing with mm/filemap.c, but also with ~90 filesystems and things sufficiently like filesystems to have an address_space_operations of their own, including graphics drivers.