Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1704032pxb; Fri, 22 Oct 2021 06:11:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1dGQOGgzkLg0llq2HM5GUH1dGODkQ/sZ0PfS7qMUkr3BiUU9matss94yOLvJQkPvCBUVP X-Received: by 2002:a05:6000:1acc:: with SMTP id i12mr15536330wry.249.1634908261347; Fri, 22 Oct 2021 06:11:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634908261; cv=none; d=google.com; s=arc-20160816; b=lm+oZtWUGS85mvL3xlBDilMk4QE8g89sH3e+Qc+rGLc7U88HFMuoMHE8dPXNe7og2+ Sqy/NXB3CTfCnkJmxM/MAcAwVA7qjydM7U8nRcwc3Mm2w9tduPfVuNayu3YCntZsMt+D NQw9Qpj95BolqvCzGeJya0dGbM6657Vu0L/QzuGdIHdpY9+/ahV1fXcx4J0wiWescfg8 rghHj118M3Mkor5e3pvXjWpLy6s9IvAFyEneuNQpVEJbLxn/2ykzcrhba8FOPsEfwu9b k/QJBGTG33GzTWI4gnmtrjxVzlx43NZc9ixqUtLHIK8TmYhofgrbcnyQSG082mV0ZSrJ MUOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ceLFPSG9PwcNCS8a9ytFESTTipwib/6u0uhFzDsr/gQ=; b=VkXRgQ498avm0zBGrCg4cVAa8vBSNYLBb5BsYdrblYxn9ZKfHRloskTVjzIU5jg/Jc 2tRt7N8SyVyed+UD4KUCnG2m2kwgE+hV7CCVFic3Gvfp8rNLLLjs6sSVkrU6Ly2R4sqo gjJ7vQNt+1IE5Sp9X7cU5ndeeq4Fcq0RrywPmWNB4Vcj8M/fGJlafIuiVraWBXjOKmcq ZNTXDF7wXqqC1vCXgbs7OgqLUy9FyclWZSoYbFsXRvMAbMjBf+ardCWp9U3AvkH2nUf6 gFNSzsIMjVv95SzgGVXTZOBNAvG/Hn+V5qSPYTig2H2crE9VSaIPNVh2PG9WLfmbNz8Y ZqCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=hgK8dCxE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i5si4294362edx.608.2021.10.22.06.10.32; Fri, 22 Oct 2021 06:11:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=hgK8dCxE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232195AbhJVNHC (ORCPT + 99 others); Fri, 22 Oct 2021 09:07:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229925AbhJVNHB (ORCPT ); Fri, 22 Oct 2021 09:07:01 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F98EC061764; Fri, 22 Oct 2021 06:04:44 -0700 (PDT) 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> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.