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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 02DF1C433E0 for ; Tue, 23 Mar 2021 15:51:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7F695619B6 for ; Tue, 23 Mar 2021 15:51:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F695619B6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EA5188D0010; Tue, 23 Mar 2021 11:51:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E551C8D0001; Tue, 23 Mar 2021 11:51:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCE778D0010; Tue, 23 Mar 2021 11:51:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id ACCE28D0001 for ; Tue, 23 Mar 2021 11:51:12 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6CAB0180A605A for ; Tue, 23 Mar 2021 15:51:12 +0000 (UTC) X-FDA: 77951577984.39.BE8961D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 04EBC2000266 for ; Tue, 23 Mar 2021 15:51:10 +0000 (UTC) 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=gZLsZmaUj7MP9DFHhIT+qX0xY3GcMrGAZzzfSLvYPHQ=; b=CIlQUqKFiXNUpG7ioNs2IRg+KR puiGG6OUEo/LBeGBlWWkkfnWPMtiqFpMHdhsha0RXh+X584qJQrdv5mNaitX2kRMt09kN7mxY2Neq tdlmhZwkkrYsxa2LQeZh9GnZjKO5yNys/tCgdo91WLha5dgJN0QAJDGjSDzgBsfY9+4xLLNxIpXB+ LNbjefqsUhpvnhhCNa5sRXkqOduQAV/B8M85/BIE4z4PJmouWLNJ9zX6dY+2BXnW0FqbOWQqVZpB3 N/osmT5lvztvSYDvqoAsPpAVzN7klcP7VSh2pfGWTbBMrPDTYgjcZviUBfRMYej6tRCdScSu1w97o a6HCdAfg==; Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lOjIu-00AF00-Ng; Tue, 23 Mar 2021 15:50:50 +0000 Date: Tue, 23 Mar 2021 15:50:48 +0000 From: Christoph Hellwig To: Johannes Weiner Cc: "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, linux-afs@lists.infradead.org Subject: Re: [PATCH v5 00/27] Memory Folios Message-ID: <20210323155048.GB2438080@infradead.org> References: <20210320054104.1300774-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-Stat-Signature: 4ssiz1w4jxrjzunfrwab1u95q6rop4ib X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 04EBC2000266 Received-SPF: none (casper.srs.infradead.org>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616514670-299605 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 Mon, Mar 22, 2021 at 01:59:24PM -0400, Johannes Weiner wrote: > If that is the case, shouldn't there in the long term only be very > few, easy to review instances of things like compound_head(), > PAGE_SIZE etc. deep in the heart of MM? And everybody else should 1) > never see tail pages and 2) never assume a compile-time page size? Probably. > But this part is already getting better, and has gotten better, with > the page cache (largely?) going native for example. As long as there is no strong typing it is going to remain a mess. > So I fully agree with the motivation behind this patch. But I do > wonder why it's special-casing the commmon case instead of the rare > case. It comes at a huge cost. Short term, the churn of replacing > 'page' with 'folio' in pretty much all instances is enormous. The special case is in the eye of the beholder. I suspect we'll end up using the folio in most FS/VM interaction eventually, which makes it the common. But I don't see how it is the special case? Yes, changing from page to folio just about everywhere causes more change, but it also allow to: a) do this gradually b) thus actually audit everything that we actually do the right thing And I think willys whole series (the git branch, not just the few patches sent out) very clearly shows the benefit of that. > And longer term, I'm not convinced folio is the abstraction we want > throughout the kernel. If nobody should be dealing with tail pages in > the first place, why are we making everybody think in 'folios'? Why > does a filesystem care that huge pages are composed of multiple base > pages internally? This feels like an implementation detail leaking out > of the MM code. The vast majority of places should be thinking 'page' > with a size of 'page_size()'. Including most parts of the MM itself. Why does the name matter? While there are arguments both ways, the clean break certainly helps every to remind everyone that this is not your grandfathers fixed sized page. > > The compile-time check is nice, but I'm not sure it would be that much > more effective at catching things than a few centrally placed warns > inside PageFoo(), get_page() etc. and other things that should not > encounter tail pages in the first place (with __helpers for the few > instances that do). Eeek, no. No amount of runtime checks is going to replace compile time type safety.