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@xxxxxxxxxxxxxx> > >> > >> 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