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 142B4C433EF for ; Fri, 22 Oct 2021 13:04:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 63D0661073 for ; Fri, 22 Oct 2021 13:04:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 63D0661073 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 C43D7900003; Fri, 22 Oct 2021 09:04:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF36E900002; Fri, 22 Oct 2021 09:04:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9587900003; Fri, 22 Oct 2021 09:04:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id 9C2E5900002 for ; Fri, 22 Oct 2021 09:04:18 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 64D75181B0496 for ; Fri, 22 Oct 2021 13:04:18 +0000 (UTC) X-FDA: 78724091796.38.30205B2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id 44BEC7001702 for ; Fri, 22 Oct 2021 13:04:15 +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=ceLFPSG9PwcNCS8a9ytFESTTipwib/6u0uhFzDsr/gQ=; b=hgK8dCxE5kiokMvHI8BrX1mKtt uSTgVRfw2SS+zqxcRwMvTW7KsBE/5jLZEwn7AeRau+yKPd1kXQhEaiCKERpKcUoIf65Hgw2fKllDe X05UHY/6IxtRHvBUa6xESlRKmUvsDTvbpwqKsu2TTiJrpx/TWKgfjhNL/i1V8yORkgaF+1HUu9Eyy kaJ9MLr18hdFV8TQYMgTUAj6vDgEJq993PdZtFSnDG4u88Zz1tykYo1vObr+OkkgLMJOIqRk++3Qt YVEoSTdIIbxsgYnMb1pxKO6NR9yz0ZoQsngHLniDwUpyBKIbGuggTXS41E9+zyymcnk8AlPvFWs6q j2CF7SGQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mduAi-00Dud6-RP; Fri, 22 Oct 2021 13:01:52 +0000 Date: Fri, 22 Oct 2021 14:01:20 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Johannes Weiner , 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> <326b5796-6ef9-a08f-a671-4da4b04a2b4f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <326b5796-6ef9-a08f-a671-4da4b04a2b4f@redhat.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 44BEC7001702 X-Stat-Signature: dnthrqkin6p4hwu4k6je77hto7wqc4t6 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=hgK8dCxE; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1634907855-891156 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 09:59:05AM +0200, David Hildenbrand wrote: > something like this would roughly express what I've been mumbling about: > > anon_mem file_mem > | | > ------|------ > lru_mem slab > | | > ------------- > | > page > > I wouldn't include folios in this picture, because IMHO folios as of now > are actually what we want to be "lru_mem", just which a much clearer > name+description (again, IMHO). I think folios are a superset of lru_mem. To enhance your drawing: page folio lru_mem anon_mem ksm file_mem netpool devmem zonedev slab pgtable buddy zsmalloc vmalloc I have a little list of memory types here: https://kernelnewbies.org/MemoryTypes Let me know if anything is missing. > Going from file_mem -> page is easy, just casting pointers. > Going from page -> file_mem requires going to the head page if it's a > compound page. > > But we expect most interfaces to pass around a proper type (e.g., > lru_mem) instead of a page, which avoids having to lookup the compund > head page. And each function can express which type it actually wants to > consume. The filmap API wants to consume file_mem, so it should use that. > > And IMHO, with something above in mind and not having a clue which > additional layers we'll really need, or which additional leaves we want > to have, we would start with the leaves (e.g., file_mem, anon_mem, slab) > and work our way towards the root. Just like we already started with slab. That assumes that the "root" layers already handle compound pages properly. For example, nothing in mm/page-writeback.c does; it assumes everything is an order-0 page. So working in the opposite direction makes sense because it tells us what has already been converted and is thus safe to call. And starting with file_mem makes the supposition that it's worth splitting file_mem from anon_mem. I believe that's one or two steps further than it's worth, but I can be convinced otherwise. For example, do we have examples of file pages being passed to routines that expect anon pages? Most routines that I've looked at expect to see both file & anon pages, and treat them either identically or do slightly different things. But those are just the functions I've looked at; your experience may be quite different.