On Wed, Aug 20, 2025 at 02:19:24PM +0100, Matthew Wilcox wrote: > On Tue, Aug 19, 2025 at 06:25:36PM -0700, Shakeel Butt wrote: > > On Wed, Aug 20, 2025 at 12:46:43AM +0100, Matthew Wilcox wrote: > > > OK, but couldn't we make that argument for anything else? Like slab, > > > say. Why's "file" memory different? > > > > Good point and I think it does apply to other memory types too. I would > > call "file" memory to be more important as it is one of the largest > > consumer of DRAM on, at least, Meta infra. Slab needs a bit more thought. > > At the system level (i.e. /proc/meminfo), we account at the page (or > > slab) level while for memcg, we account per-object (plus obj_cgroup > > pointer). > > That was supposed to be a reductio ad absurdum, not an invitation to > add more counters. > > Look, if this is information you really need, I think you should come > up with a better way of collecting it than by adding new counters and > new complexity to everything involved in GFP_ACCOUNT activities. > Please elaborate more on this complexity. To me, particularly for this specific case, a dedicated counter seems more cleaner compared to error prone and costly alternatives. I am not getting the complexity argument. > The unaccounted address_spaces are a very tiny percentage of file > memory, at least as far as this patch set goes. >From [1], Qu noted "On a real world system, the metadata itself can easily go hundreds of GiBs...". This does not seem tiny. > I don't think this > patch is justifiable on its face. I think I have provided enough justifications. However I don't want to force push this until I fully understand your concerns. This will become part of API and I don't want a situation where we regret this later. [1] https://lore.kernel.org/linux-mm/08ccb40d-6261-4757-957d-537d295d2cf5@xxxxxxxx/
