On Mon 22-08-22 19:22:26, Roman Gushchin wrote: > On Mon, Aug 22, 2022 at 09:34:59PM +0200, Michal Hocko wrote: > > On Mon 22-08-22 11:37:30, Roman Gushchin wrote: > > [...] > > > I wonder only if we want to make it configurable (Idk a sysctl or maybe > > > a config option) and close the topic. > > > > I do not think this is a good idea. We have other examples where we have > > outsourced internal tunning to the userspace and it has mostly proven > > impractical and long term more problematic than useful (e.g. > > lowmem_reserve_ratio, percpu_pagelist_high_fraction, swappiness just to > > name some that come to my mind). I have seen more often these to be used > > incorrectly than useful. > > A agree, not a strong opinion here. But I wonder if somebody will > complain on Shakeel's change because of the reduced accuracy. > I know some users are using memory cgroups to track the size of various > workloads (including relatively small) and 32->64 pages per cpu change > can be noticeable for them. But we can wait for an actual bug report :) Yes, that would be my approach. I have seen reports like that already but that was mostly because of heavy caching on the SLUB side on older kernels. So there surely are workloads with small limits configured (e.g. 20MB). On the other hand those users were receptive to adapt their limits as they were kinda arbitrary anyway. > > In this case, I guess we should consider either moving to per memcg > > charge batching and see whether the pcp overhead x memcg_count is worth > > that or some automagic tuning of the batch size depending on how > > effectively the batch is used. Certainly a lot of room for > > experimenting. > > I'm not a big believer into the automagic tuning here because it's a fundamental > trade-off of accuracy vs performance and various users might make a different > choice depending on their needs, not on the cpu count or something else. Yes, this not an easy thing to get right. I was mostly thinking some auto scaling based on the limit size or growing the stock if cache hits are common and decrease when stocks get flushed often because multiple memcgs compete over the same pcp stock. But to me it seems like a per memcg approach might lead better results without too many heuristics (albeit more memory hungry). > Per-memcg batching sounds interesting though. For example, we can likely > batch updates on leaf cgroups and have a single atomic update instead of > multiple most of the times. Or do you mean something different? No, that was exactly my thinking as well. -- Michal Hocko SUSE Labs
