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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 88800C433FE for ; Mon, 13 Sep 2021 11:32:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 40E6960F4A for ; Mon, 13 Sep 2021 11:32:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 40E6960F4A Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BFA336B0071; Mon, 13 Sep 2021 07:32:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB390900003; Mon, 13 Sep 2021 07:32:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABF6C900002; Mon, 13 Sep 2021 07:32:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 9F2046B0071 for ; Mon, 13 Sep 2021 07:32:32 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 65B06180AD81A for ; Mon, 13 Sep 2021 11:32:32 +0000 (UTC) X-FDA: 78582337344.11.9A1EC40 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf29.hostedemail.com (Postfix) with ESMTP id E52E5900024A for ; Mon, 13 Sep 2021 11:32:31 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id BB1091FFCB; Mon, 13 Sep 2021 11:32:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1631532750; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MmOXV82ZmaGCqV2USJ7r1chshtX3p4vyPS/RDmpH9Kk=; b=vHJ/IqG0alI4RYXeXt2lzVpnkym3TKly6X3vzChUlIH1R77qODq709I17odCQgvkv/UxpH SKwrSpddX9iSgeoKOV4V6QpnuH3hpMbTYda2XSHEp8O7Arah0suPYatmAWfRLjZFRXvzgO +AxoNOvttcegmZToweCpn1IdmB1u81A= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 8C2C3A3B88; Mon, 13 Sep 2021 11:32:30 +0000 (UTC) Date: Mon, 13 Sep 2021 13:32:30 +0200 From: Michal Hocko To: "Kirill A. Shutemov" Cc: Kent Overstreet , Matthew Wilcox , Johannes Weiner , 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: <20210911012324.6vb7tjbxvmpjfhxv@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210911012324.6vb7tjbxvmpjfhxv@box.shutemov.name> Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="vHJ/IqG0"; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E52E5900024A X-Stat-Signature: h8t59wsqpesoa85j6q4u8km3uhtciewi X-HE-Tag: 1631532751-715461 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 Sat 11-09-21 04:23:24, Kirill A. Shutemov wrote: > On Fri, Sep 10, 2021 at 04:16:28PM -0400, Kent Overstreet wrote: > > So we should listen to the MM people. > > Count me here. > > I think the problem with folio is that everybody wants to read in her/his > hopes and dreams into it and gets disappointed when see their somewhat > related problem doesn't get magically fixed with folio. > > Folio started as a way to relief pain from dealing with compound pages. > It provides an unified view on base pages and compound pages. That's it. > > It is required ground work for wider adoption of compound pages in page > cache. But it also will be useful for anon THP and hugetlb. > > Based on adoption rate and resulting code, the new abstraction has nice > downstream effects. It may be suitable for more than it was intended for > initially. That's great. > > But if it doesn't solve your problem... well, sorry... > > The patchset makes a nice step forward and cuts back on mess I created on > the way to huge-tmpfs. > > I would be glad to see the patchset upstream. I do agree here. While points that Johannes brought up are relevant and worth thinking about I do also see a clear advantage of folio (or whatever $name) is bringing. The compound page handling is just a mess and source of practical problems and bugs. This really requires some systematic approach to deal with it. The proposed type system is definitely a good way to approach it. Johannes is not happy about having the type still refer to page units but I haven't seen an example where that leads to a worse or harder to maintain code so far. The evolution is likely not going to stop at the current type system but I haven't seen any specifics to prove it would stand in the way. The existing code (fs or other subsystem interacting with MM) is going to require quite a lot of changes to move away from struct page notion but I do not see folios to add fundamental blocker there. All that being said, not only I see folios to be a step into the right direction to address compound pages mess it is also a code that already exists and gives some real advantages. I haven't heard anybody subscribing to a different approach and providing an implementation in a foreseeable future so I would rather go with this approach then dealing with the existing code long term. -- Michal Hocko SUSE Labs