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.5 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 50C5EC433F5 for ; Tue, 21 Sep 2021 20:40:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D46A261165 for ; Tue, 21 Sep 2021 20:40:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D46A261165 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3C9536B006C; Tue, 21 Sep 2021 16:40:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3782C6B0071; Tue, 21 Sep 2021 16:40:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2667F900002; Tue, 21 Sep 2021 16:40:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 1398C6B006C for ; Tue, 21 Sep 2021 16:40:11 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AEB26181C65C3 for ; Tue, 21 Sep 2021 20:40:10 +0000 (UTC) X-FDA: 78612747780.01.FB4A743 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 3DD9590000A2 for ; Tue, 21 Sep 2021 20:40: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=GVJlkCVZHRNXzlp5wu6spEzRD7PBCcXgh0lGOQnwm5A=; b=W1tKb5WjUS/ACQUPHSdZb1RSrc NgMe8M7KBYZNkOL82B+Dc/CM1NocR8vFQ12l04IpNYY63bsZJDjqAIKR5nt5fa8dEl1F23ZbvhVLU hHPxd+Z6FLOH8bGYP3gCe0Abl6n6bcLsYxa03BZNJR2KNAnBsqumj7TWl7DBhpfSQPK1INswyt6M7 wj8CMMFe4t8meFysy+xU3ldQcdQXGcOy74+pMzepEE23OdhgUAyEDqp1fz/eOnC9N1QyCJK8rJCkv 3GI/uq3qf47vctHS0CmJheWrdCUz+Y1fVF+IMnrG0ZLPIaWslGm4DpOvJm1ov8ewjG75z3J/orE7m UVXkGUZQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSmXW-0049bT-IU; Tue, 21 Sep 2021 20:39:14 +0000 Date: Tue, 21 Sep 2021 21:38:54 +0100 From: Matthew Wilcox To: Johannes Weiner Cc: 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 Subject: Re: Folio discussion recap Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 47c7myt48xrscjyhc4acwqwnqa4y5two Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=W1tKb5Wj; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3DD9590000A2 X-HE-Tag: 1632256810-626473 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 Tue, Sep 21, 2021 at 03:47:29PM -0400, Johannes Weiner wrote: > This discussion is now about whether folio are suitable for anon pages > as well. I'd like to reiterate that regardless of the outcome of this > discussion I think we should probably move ahead with the page cache > bits, since people are specifically blocked on those and there is no > dependency on the anon stuff, as the conversion is incremental. So you withdraw your NAK for the 5.15 pull request which is now four weeks old and has utterly missed the merge window? > and so the justification for replacing page with folio *below* those > entry points to address tailpage confusion becomes nil: there is no > confusion. Move the anon bits to anon_page and leave the shared bits > in page. That's 912 lines of swap_state.c we could mostly leave alone. Your argument seems to be based on "minimising churn". Which is certainly a goal that one could have, but I think in this case is actually harmful. There are hundreds, maybe thousands, of functions throughout the kernel (certainly throughout filesystems) which assume that a struct page is PAGE_SIZE bytes. Yes, every single one of them is buggy to assume that, but tracking them all down is a never-ending task as new ones will be added as fast as they can be removed. > The same is true for the LRU code in swap.c. Conceptually, already no > tailpages *should* make it onto the LRU. Once the high-level page > instantiation functions - add_to_page_cache_lru, do_anonymous_page - > have type safety, you really do not need to worry about tail pages > deep in the LRU code. 1155 more lines of swap.c. It's actually impossible in practice as well as conceptually. The list LRU is in the union with compound_head, so you cannot put a tail page onto the LRU. But yet we call compound_head() on every one of them multiple times because our current type system does not allow us to express "this is not a tail page". > The anon_page->page relationship may look familiar too. It's a natural > type hierarchy between superclass and subclasses that is common in > object oriented languages: page has attributes and methods that are > generic and shared; anon_page and file_page encode where their > implementation differs. > > A type system like that would set us up for a lot of clarification and > generalization of the MM code. For example it would immediately > highlight when "generic" code is trying to access type-specific stuff > that maybe it shouldn't, and thus help/force us refactor - something > that a shared, flat folio type would not. If you want to try your hand at splitting out anon_folio from folio later, be my guest. I've just finished splitting out 'slab' from page, and I'll post it later. I don't think that splitting anon_folio from folio is worth doing, but will not stand in your way. I do think that splitting tail pages from non-tail pages is worthwhile, and that's what this patchset does.