Re: [PATCH v2] mm: slub: Convert sys slab alloc_calls, free_calls to bin attribute

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Mar 19, 2021 at 10:58:55AM +0530, Faiyaz Mohammed wrote:
> Hi,
> 
> Sorry for late response!
> 
> On 3/2/2021 6:41 PM, Greg Kroah-Hartman wrote:
> > On Tue, Mar 02, 2021 at 01:59:46PM +0100, Vlastimil Babka wrote:
> >> On 2/17/21 7:31 AM, Faiyaz Mohammed wrote:
> >>> Reading the sys slab alloc_calls, free_calls returns the available object
> >>> owners, but the size of this file is limited to PAGE_SIZE
> >>> because of the limitation of sysfs attributes, it is returning the
> >>> partial owner info, which is not sufficient to debug/account the slab
> >>> memory and alloc_calls output is not matching with /proc/slabinfo.
> >>>
> >>> To remove the PAGE_SIZE limitation converted the sys slab
> >>> alloc_calls, free_calls to bin attribut
> >>>
> >>> Signed-off-by: Faiyaz Mohammed <faiyazm@codeaurora.org>
> >>
> >> After discussing this with Greg and PeterZ, sysfs should be one value per file,
> >> and is just not proper API for this kind of info. We should reimplement at least
> >> these clearly debugging "attributes" in debugfs, where they belong, instead of
> >> trying to hack around the limitation in sysfs.
> > 
> > sysfs is _REQUIRED_ to be "one value per file", any kernel code that
> > abuses this needs to be fixed up.
> > 
> > Why are these slab files in sysfs at all anyway?  They all feel like
> > debugging stuff to me, why not move everything to debugfs?  Would make
> > for a lot less code overall.
> > 
> Yes, we can move the /sys/kernel/slab/kmemcache/alloc_calls and
> /sys/kernel/slab/kmemcache/free_calls implementation to debugfs but is
> it okay to move only alloc_calls and free_calls? or we have to move
> whole sysfs interface to debugfs?.

sysfs files should only have "one value" in them.  Anything that
violates that rule, should be moved to debugfs.

thanks,

greg k-h