On Mon, Jun 22, 2020 at 11:09:47AM -0700, Shakeel Butt wrote: > On Mon, Jun 22, 2020 at 11:02 AM Roman Gushchin <guro@xxxxxx> wrote: > > > > On Mon, Jun 22, 2020 at 10:12:46AM -0700, Shakeel Butt wrote: > > > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin <guro@xxxxxx> wrote: > > > > > > > > Deprecate memory.kmem.slabinfo. > > > > > > > > An empty file will be presented if corresponding config options are > > > > enabled. > > > > > > > > The interface is implementation dependent, isn't present in cgroup v2, > > > > and is generally useful only for core mm debugging purposes. In other > > > > words, it doesn't provide any value for the absolute majority of users. > > > > > > > > A drgn-based replacement can be found in tools/cgroup/slabinfo.py . > > > > It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output > > > > and also allows to get any additional information without a need > > > > to recompile the kernel. > > > > > > > > If a drgn-based solution is too slow for a task, a bpf-based tracing > > > > tool can be used, which can easily keep track of all slab allocations > > > > belonging to a memory cgroup. > > > > > > > > Signed-off-by: Roman Gushchin <guro@xxxxxx> > > > > Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx> > > > > Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx> > > > > > > Hi Roman, > > > > > > I am not against removing the memory.kmem.slabinfo interface but I > > > would like to have an alternative solution more accessible than > > > tools/cgroup/slabinfo.py. > > > > > > In our case, we don't have ssh access and if we need something for > > > debugging, it is much more preferable to provide a file to read to > > > SREs. After the review, that file will be added to a whitelist and > > > then we can directly read that file through automated tools without > > > approval for each request. > > > > > > I am just wondering if a file interface can be provided for whatever > > > tools/cgroup/slabinfo.py is providing. > > > > > > Shakeel > > > > Hello, Shakeel! > > > > I understand your point, but Idk how much we wanna make this code a part > > of the kernel and the cgroup interface. > > No need for the cgroup interface. I was thinking of a new interface > like /proc/slabinfo_full which tells active objects for each > kmem_cache and memcg pair. To me it's a perfect example where tools like drgn and bpf shine. They are more flexible and do not blow the kernel up with the debug-only code. > > > The problem is that reading > > from it will be really slow in comparison to all other cgroup interface > > files. Idk if Google's version of SLAB has a list of all slab pages, > > but if not (as in generic SLUB case), it requires scanning of the whole RAM. > > That's a bummer. Does drgn-based script scan the whole RAM? To be precise, not over all RAM, but over all struct pages. Unfortunately, there is no better option with SLUB, as there is no comprehensive list of slab pages available. So the only option is to scan over all pages with PageSlab flag set. Thanks!
