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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92B81C433F5 for ; Fri, 17 Sep 2021 16:59:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 06D0660F6E for ; Fri, 17 Sep 2021 16:59:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 06D0660F6E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A19316B0072; Fri, 17 Sep 2021 12:59:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A4826B0073; Fri, 17 Sep 2021 12:59:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 869B36B0074; Fri, 17 Sep 2021 12:59:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id 76E166B0072 for ; Fri, 17 Sep 2021 12:59:02 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 18BDD8245578 for ; Fri, 17 Sep 2021 16:59:02 +0000 (UTC) X-FDA: 78597675324.32.8B3B325 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf03.hostedemail.com (Postfix) with ESMTP id E75DD331DE36 for ; Fri, 17 Sep 2021 16:29:39 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id bk29so19146875qkb.8 for ; Fri, 17 Sep 2021 09:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2HsUkQ8fOhjXi15MPOztE8TxIV5X+XjzP3rW1H5zjpE=; b=fAhePr+69OVHmQY9xBibvJ55dFKWkjATxQFOb1dSZ4d1ppoo1W8a5gfDnc+V09uQ3L sqQtKrefilO7h1KhAKOJDJ3qbsSiGVDAEk/ZUaeOx0GiiFH7m+V179i7cmMGAU267z48 CLmeRZfmsG20emvyvzXKokLaNqJ2Lh7SDXAahUfWvSR0svSH/+jKEovNftzE9YYPKJoN xZw2RKhE1fFetfJtvRegP/3m4eWGSCzrQ6gBPBCgvgZWiFA7ITWiDc1kJLSywrg85NsC tVOei5vByQSVEbivTPyRNcrRt6/WALKyQDqtf75vnimOfM11BFpZ2hEUlg0uiFI3fpu9 113Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2HsUkQ8fOhjXi15MPOztE8TxIV5X+XjzP3rW1H5zjpE=; b=D495LNF0gIJFYAE3LgTv7H4/7RcPWFkEe3KTfq1ShwF8LrvSMaJp/ldlfwIc6vRfsJ QSOG2h5ZT5JFBh7a5+026JpLwKhGkwXkQt8NTF//cFXaLfTn8aOnG2RHVRys19uNzNKw ayPK8KnK4xEJ4TsL3fYaT2mDTTHZHUMPCywGI171DLCE4VW4Odcnq6bgVhUq7zIwRIZK Faoygq/LGrN+5Dpodzp5gB4RmT9/UUocf5LLW4XIP59GATMUuWHJuv0+NohuVvOFKjLc 8BhDZyoxdVwkx70rdOyMRkNQzw/PgIXm0Sq+RoLHoxBtq01dKrPXoK7eZLZqmqLJKT4N g4SA== X-Gm-Message-State: AOAM533mfqBa3nsFPavj9R8XlRFggi8mCtdRm0DuT2V7CyrOdBQ6uodE 4NJaPC9YWwyX/giL6089ezSqzQ== X-Google-Smtp-Source: ABdhPJzBDURl+kSs7t3ZrvSGWold3Z4S+tq7SXdrj56e46TPU+eR8IWCyZQyyrag5BvKMjDg4Hgs9g== X-Received: by 2002:a05:620a:c05:: with SMTP id l5mr11460700qki.17.1631896179116; Fri, 17 Sep 2021 09:29:39 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id j6sm4284123qtp.97.2021.09.17.09.29.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Sep 2021 09:29:38 -0700 (PDT) Date: Fri, 17 Sep 2021 12:31:36 -0400 From: Johannes Weiner To: Dave Chinner Cc: "Darrick J. Wong" , Kent Overstreet , Matthew Wilcox , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig , David Howells Subject: Re: Folio discussion recap Message-ID: References: <20210916025854.GE34899@magnolia> <20210917052440.GJ1756565@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210917052440.GJ1756565@dread.disaster.area> Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=fAhePr+6; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Stat-Signature: e3mmb496317jdzp64uw14xfzzhu5wsrq X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E75DD331DE36 X-HE-Tag: 1631896179-849961 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: On Fri, Sep 17, 2021 at 03:24:40PM +1000, Dave Chinner wrote: > On Thu, Sep 16, 2021 at 12:54:22PM -0400, Johannes Weiner wrote: > > I agree with what I think the filesystems want: instead of an untyped, > > variable-sized block of memory, I think we should have a typed page > > cache desciptor. > > I don't think that's what fs devs want at all. It's what you think > fs devs want. If you'd been listening to us the same way that Willy > has been for the past year, maybe you'd have a different opinion. I was going off of Darrick's remarks about non-pagecache uses, Kent's remarks Kent about simple and obvious core data structures, and yes your suggestion of "cache page". But I think you may have overinterpreted what I meant by cache descriptor: > Indeed, we don't actually need a new page cache abstraction. I didn't suggest to change what the folio currently already is for the page cache. I asked to keep anon pages out of it (and in the future potentially other random stuff that is using compound pages). It doesn't have any bearing on how it presents to you on the filesystem side, other than that it isn't as overloaded as struct page is with non-pagecache stuff. A full-on disconnect between the cache entry descriptor and the page is something that came up during speculation on how the MM will be able to effectively raise the page size and meet scalability requirements on modern hardware - and in that context I do appreciate you providing background information on the chunk cache, which will be valuable to inform *that* discussion. But it isn't what I suggested as the immediate action to unblock the folio merge. > The fact that so many fs developers are pushing *hard* for folios is > that it provides what we've been asking for individually over last > few years. I'm not sure filesystem people are pushing hard for non-pagecache stuff to be in the folio. > Willy has done a great job of working with the fs developers and > getting feedback at every step of the process, and you see that in > the amount of work that in progress that is already based on > folios. And that's great, but the folio is blocked on MM questions: 1. Is the folio a good descriptor for all uses of anon and file pages inside MM code way beyond the page cache layer YOU care about? 2. Are compound pages a scalable, future-proof allocation strategy? For some people the answers are yes, for others they are a no. For 1), the value proposition is to clean up the relatively recent head/tail page confusion. And though everybody agrees that there is value in that, it's a LOT of churn for what it does. Several people have pointed this out, and AFAICS this is the most common reason for people that have expressed doubt or hesitation over the patches. In an attempt to address this, I pointed out the cleanup opportunities that would open up by using separate anon and file folio types instead of one type for both. Nothing more. No intermediate thing, no chunk cache. Doesn't affect you. Just taking Willy's concept of type safety and applying it to file and anon instead of page vs compound page. - It wouldn't change anything for fs people from the current folio patchset (except maybe the name) - It would accomplish the head/tail page cleanup the same way, since just like a folio, a "file folio" could also never be a tail page - It would take the same solution folio prescribes to the compound page issue (explicit typing to get rid of useless checks, lookups and subtle bugs) and solve way more instances of this all over MM code, thereby hopefully boosting the value proposition and making *that part* of the patches a clearer win for the MM subsystem This is a question directed at MM people, not filesystem people. It doesn't pertain to you at all. And if MM people agree or want to keep discussing it, the relatively minor action item for the folio patch is the same: drop the partial anon-to-folio conversion bits inside MM code for now and move on. For 2), nobody knows the answer to this. Nobody. Anybody who claims to do so is full of sh*t. Maybe compound pages work out, maybe they don't. We can talk a million years about larger page sizes, how to handle internal fragmentation, the difficulties of implementing a chunk cache, but it's completely irrelevant because it's speculative. We know there are multiple page sizes supported by the hardware and the smallest supported one is no longer the most dominant one. We do not know for sure yet how the MM is internally going to lay out its type system so that the allocator, mmap, page reclaim etc. can be CPU efficient and the descriptors be memory efficient. Nobody's "grand plan" here is any more viable, tested or proven than anybody else's. My question for fs folks is simply this: as long as you can pass a folio to kmap and mmap and it knows what to do with it, is there any filesystem relevant requirement that the folio map to 1 or more literal "struct page", and that folio_page(), folio_nr_pages() etc be part of the public API? Or can we keep this translation layer private to MM code? And will page_folio() be required for anything beyond the transitional period away from pages? Can we move things not used outside of MM into mm/internal.h, mark the transitional bits of the public API as such, and move on? The unproductive vitriol, personal attacks and dismissiveness over relatively minor asks and RFCs from the subsystem that is the most impacted by this patchset is just nuts.