On Tue, Feb 27, 2024 at 9:17 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Tue 27-02-24 20:12:27, Yafang Shao wrote: > > On Tue, Feb 27, 2024 at 8:09 PM Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > [...] > > > > If that's the case, why was slabs info initially exposed through > > > > /proc/slabinfo? > > because that helps to better understand the memory consumption by slab > consumers. > > > > > Isn't that level of detail considered a kernel > > > > implementation detail? Currently, users can identify which slab is > > > > consuming the most memory but lack the ability to take action based on > > > > that information. This suggests a flaw in the kernel implementation. > > I disgree! > > > > BTW, we even expose more detailed kernel implementation details > > > through /sys/kernel/slab. > > > That is really confusing... > > > > There is even a /sys/kernel/slab/dentry/shrink .... > > oh please... > > We also have /proc/sys/vm/drop_caches and we have learned those are > really terrible interfaces and we have good reasons to not replicate > those into memcg interfaces. Using bad interfaces as an example is not > the way argue for new ones. And then we introduce a similar memory.reclaim...... -- Regards Yafang
