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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB6E6C433FE for ; Mon, 25 Oct 2021 15:35:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2814460E97 for ; Mon, 25 Oct 2021 15:35:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2814460E97 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 7AEA980007; Mon, 25 Oct 2021 11:35:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75EE7940007; Mon, 25 Oct 2021 11:35:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FFCC80007; Mon, 25 Oct 2021 11:35:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0240.hostedemail.com [216.40.44.240]) by kanga.kvack.org (Postfix) with ESMTP id 5267A940007 for ; Mon, 25 Oct 2021 11:35:29 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id F0EF2182012AC for ; Mon, 25 Oct 2021 15:35:28 +0000 (UTC) X-FDA: 78735359136.40.15C0D17 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf25.hostedemail.com (Postfix) with ESMTP id A2DA0B000184 for ; Mon, 25 Oct 2021 15:35:22 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id y10so12054773qkp.9 for ; Mon, 25 Oct 2021 08:35:28 -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=APD+8v+yzG8mONZt5PB1dtOtV91cn6z6YYGiPhcEgzo=; b=CZaXqzxgV/rFXwcgME6NqnXsQ2goBIjelkXHFJWnQcpvj8y/TgAuRvl1PplMgFMRk9 3NeQRqG0cgoeOAyt4otEEMtnupURSPQnffElUrBbakcf5GHNQRYYjEBbBh7per+4WjTd 5mcpx+8Y7OSDPjwvdaGXaDiF0A4jDQ+V+Nuo+Y98Saezte+NRxzJpqwnOQ65PsL5mB4u 3A9AIUTPKaNLCUotpFMISOnVrGrM9f1u0qTDIGNxDl++B8T2DUETdBLlXg0QBGqzKRlU g1vSkVFXOWF7o8DFyVZRhOW4UXcgnoGA3T1niASsvcEk4BFF2zKLow7cl/6i0sBXErcM DdCg== 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=APD+8v+yzG8mONZt5PB1dtOtV91cn6z6YYGiPhcEgzo=; b=sYsWN/D3ynZ25VtXpqr6+PhQ192nFqHW/Z6pDtebqSbrlCwtG/PdRV0t8YzCQ6UwY0 PEth+qYX/x+ypHtzyfwaJdX9yuhVg13AGnyhL3vxE1QeWEow10XdunnorK9qh6cHAnDn U6mhlYDMW/Otr8mmZrGHBwNa9jsGJ4+8g8qi4FSx6/CRMVl6qexCb/3WMrnhB3Al6Poh 4jRqGFc51qzlr8Xwe2uSMrEDybuzuqyJyV3LBPlpWNOVeg96ahxMX5IHl3+DGLv9y3cv 12HeFQiX3IIyZvvT23FoMCqj5odT8ZLRg9EVuRjciPqzrhivuyp8BlA/vsMMgjmVhhsU 7N/w== X-Gm-Message-State: AOAM533St8Bn0wBPLNpKwxMOxVprCeLjnxx7TvwnrxGyZKf/nte5sk2H /+WKG5oP7Rd7vmMYidgrhfOADA== X-Google-Smtp-Source: ABdhPJzmVFGhPfVSLkQOPVn1nGoegSO3FOQ76nXsoSKE95o+yQ+MZFcyN6qf3Zw8X8sO51h9V6juHg== X-Received: by 2002:a37:aa43:: with SMTP id t64mr13450043qke.233.1635176127558; Mon, 25 Oct 2021 08:35:27 -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 t26sm8649908qtq.77.2021.10.25.08.35.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 08:35:26 -0700 (PDT) Date: Mon, 25 Oct 2021 11:35:25 -0400 From: Johannes Weiner To: Matthew Wilcox Cc: Kent Overstreet , "Kirill A. Shutemov" , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A2DA0B000184 X-Stat-Signature: fni4zjsdckgzyeu3666a6ox8rm4865sm Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=CZaXqzxg; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf25.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.179 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-HE-Tag: 1635176122-19696 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, Oct 22, 2021 at 02:52:31AM +0100, Matthew Wilcox wrote: > > Anyway. I can even be convinved that we can figure out the exact fault > > lines along which we split the page down the road. > > > > My worry is more about 2). A shared type and generic code is likely to > > emerge regardless of how we split it. Think about it, the only world > > in which that isn't true would be one in which either > > > > a) page subtypes are all the same, or > > b) the subtypes have nothing in common > > > > and both are clearly bogus. > > Amen! > > I'm convinced that pgtable, slab and zsmalloc uses of struct page can all > be split out into their own types instead of being folios. They have > little-to-nothing in common with anon+file; they can't be mapped into > userspace and they can't be on the LRU. The only situation you can find > them in is something like compaction which walks PFNs. They can all be accounted to a cgroup. pgtables are tracked the same as other __GFP_ACCOUNT pages (pipe buffers and kernel stacks right now from a quick grep, but as you can guess that's open-ended). So if those all aren't folios, the generic type and the interfacing object for memcg and accounting would continue to be the page. > Perhaps you could comment on how you'd see separate anon_mem and > file_mem types working for the memcg code? Would you want to have > separate lock_anon_memcg() and lock_file_memcg(), or would you want > them to be cast to a common type like lock_folio_memcg()? That should be lock__memcg() since it actually serializes and protects the same thing for all subtypes (unlike lock_page()!). The memcg interface is fully type agnostic nowadays, but it also needs to be able to handle any subtype. It should continue to interface with the broadest, most generic definition of "chunk of memory". Notably it does not do tailpages (and I don't see how it ever would), so it could in theory use the folio - but only if the folio is really the systematic replacement of absolutely *everything* that isn't a tailpage - including pgtables, kernel stack, pipe buffers, and all other random alloc_page() calls spread throughout the code base. Not just conceptually, but an actual wholesale replacement of struct page throughout allocation sites. I'm not sure that's realistic. So I'm thinking struct page will likely be the interfacing object for memcg for the foreseeable future.