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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93DA5C677C4 for ; Wed, 11 Jun 2025 03:36:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4E176B008C; Tue, 10 Jun 2025 23:36:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DFFB26B0092; Tue, 10 Jun 2025 23:36:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D17556B0095; Tue, 10 Jun 2025 23:36:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B18906B008C for ; Tue, 10 Jun 2025 23:36:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 54645121B32 for ; Wed, 11 Jun 2025 03:36:33 +0000 (UTC) X-FDA: 83541707466.11.17FB41B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id D8BE0140009 for ; Wed, 11 Jun 2025 03:36:30 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TSalIn8d; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749612991; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0SPKynNyrQCJ5TtvP3H93hmE672Ls50DpMdELI0NBJs=; b=wxm/0HrECF38mo8WhvlVPO1JdYlKJq1wOVUbHcWmXpFelRv2/cHa+BtBceTwFsS0okKCsY KmEM35RUI2SR8az+QfdBG49VjGRG7wrWZC8T90q0M1ejptixpkS4mblAUhHAkG4Mquykpy NJ9I0cAHwDQwoYS/eW72t2JNK17FwDM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TSalIn8d; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749612991; a=rsa-sha256; cv=none; b=CFu0wNOXXA1qodVzgMGr3WW/2PLlyJJu2rhApKKcMUkWyxB/PSF7SRr9vKi9C5I/c0WMBX NPknd3Q4X2oSGG+ar5qGyPkbsmj7qcLIxTOAsq1ZVGmJfJszOrR/uTawuYSba+gh2VVt9Q Ni8E4OsoRPSQGvDVx6hB4DE2ojklne4= 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=0SPKynNyrQCJ5TtvP3H93hmE672Ls50DpMdELI0NBJs=; b=TSalIn8d/JF6OvdR54xebWm8Sw +MGSmJLrl9QY7lRYplLFxA0/hHBWzv8PGzMWNRG2YKZT1KoBIfh90A0WPsFxhz8UH9MSNha0dI21s x1y+a3Mxutz48cIFcz6sdtuSAua0ESyeGTCyanbVwiyPqMI4GMJcHryFGzWs7qguWajrP101kYjh+ rdXqCrxNYOFzLwsUBR8PqYlG6KuDG7nBzzOrS/3G293h23QYriDpX0IIBmzoEL0oxZNaaF8lXB/CI 5z87QTzkAJ7Vm39rsQ2zPPAXLfVDmtFldPxGTJxN2uxdzmRrnyHRMEK0GWtZ/FUrnc1OslyCrMiUG OD7+6J2w==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uPCGK-0000000AAnD-0NIk; Wed, 11 Jun 2025 03:36:28 +0000 Date: Wed, 11 Jun 2025 04:36:27 +0100 From: Matthew Wilcox To: Dave Airlie Cc: Dave Chinner , Kairui Song , Johannes Weiner , Linux Memory Management List Subject: Re: list_lru isolate callback question? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D8BE0140009 X-Stat-Signature: fr6qjmgyuheu6p7h6omzm6g7gkfo81b9 X-Rspam-User: X-HE-Tag: 1749612990-659321 X-HE-Meta: U2FsdGVkX19zRyXNXiZzRpg/+PBOvdlMZhjfzE8V6yV9dUVs6aVnE7DDLAYT0yY5KTnNsHnK9K+xCo7Dz9LPpi9VW1/CEDe+7Obux8AbhBQqbNYjfS499fJMabxWy2JtgdHVGfqhsh83noTe1nXXdGS2noP8M3u6UA+0N7y1otVg/KfXLELqLMALudOS3cr9wouiUF7T2TjTA5qxtOSi7hUwnN+z+sRfchxiIwyNMsBTvUZt6nRwmioqMMvzNe8qmc5cFIywaj1YPAVzjNNiXOyRj4adyHn2f3/2JxLR6ZPE4FaIOJtTLUn+E+qV3PFBRDxHaBdgb+q/0Y7EJpn8ZIrtQ/pQJAg6/zliI53SBW3eIFnx0sAxjL/VH34P9YrpCpd8sYabBS/AHPV9DLRy/UFZYz5WT2Um+od0HR1o0/YJINc66c8NwfsASzC1dnxDToQgOH63zAOQEHOIIATQkIN3MYdqE+XA34i3MH4dDwOriCNmSK/q3TNRlH5CbCwqnAU5NQlQBb+i+8+Ag174M//EkdmjlZt1DsHRL0X9TrKdDkpUbaFLF+AgHaBc7wMkVNjpafaIvw06EUZHhmpPtzhiMdzPc5XCYRynBfvx3M4t1VYGXnlLtYO9+0Vihu68Ybm8qGagl8N3bB2L8zPnYk4B4gTGhfaOeHv3zSbqGHetTzC5fNpnfTUbrB8q+ecaAik/dsBSmSNCZ2qEybeoyEJit0XcDr61z0zzPAuDZh6OGQTFX/fUIzwdzXemn+EhQc9CVxoIiseFRI6wYGL8slQnpGg5/OnBeOX3Ffzm2K8VBOw29IuhlKDPCo95pXDij8Gx7AEQlmYUhtC1ZjJ8zabDFytxlLJ8FEdKxjuTIgKTHRStpNwzpLQxCk1qLVCN+0C+xamUaCrfhgpg+OcMiLNVlZQEHY/TtTE99/lU6IqHLG9QapuPTPMX8TPCnppihnf8e+/KwU3GCQMgOAr U9ZR5oMO Qpk6+5V/D6pydvzzzlGwmvdHJAc5UPlzrOj37/unVl5+dz5l23ZqDgAJkuaLzhXYoGvh7fNUZJefOSBUsiZ+Z1zvX7IWOPt8gs+GwFGe6zdgRLBqorXg8yVNuqFdrMztSC1m/9mA8Htcsn201HUrpHLfZfJ3/+/T52kqM1vooovXZEHSyugcWZ0eGsuuQNOH7IpBt62UzU9VOVCzKT3k7BfYs0MtB3KssMNJCXxLHelTx5iVA4a6dS6SKqULNyQM5xEp8Na2bZe1e1otMkY8sr+SLxR+CmCuXbhjZBIRtf5VRgH6tnYAVyMf+ep4ow+Epsbny 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: List-Subscribe: List-Unsubscribe: On Fri, Jun 06, 2025 at 08:59:16AM +1000, Dave Airlie wrote: > Also handwave shouldn't this all be folios at some point. Maybe? The question is what per-allocation data do you need to track? For filesystems, it's quite extensive, and that's what folios do. They track the filesystem object (address_space), location within that object (index), per-folio filesystem state (something like buffer_head or iomap folio state), a bunch of flags (dirty/uptodate/locked/writeback/...), LRU list, mapcount, refcount, memcg, etc, etc. If, for example, you need to go from page to "which pool does this page belong to?", that would be a good thing you could keep in your memdesc. You can certainly have some flags. It sounds like you don't need per-allocation memcg; you keep track of memcg per pool (I have a feeling that filesystems would do just as well keeping track of memcgs per inode rather than per folio, but that's a fight for the future). What I would like is for you to do something like 'struct slab' and keep your metadata in the same bits as struct page, but not messing with the contents of struct page. So don't use page->index to store an integer just because it has the right type, define your own type. Happy to help with some of this.