2014-12-12 14:40 GMT+08:00 Minchan Kim <[email protected]>: > On Fri, Dec 12, 2014 at 01:53:16PM +0800, Ganesh Mahendran wrote: >> Hello Minchan >> >> 2014-12-12 7:40 GMT+08:00 Minchan Kim <[email protected]>: >> > Hello Ganesh, >> > >> > On Wed, Dec 10, 2014 at 09:40:20PM +0800, Ganesh Mahendran wrote: >> >> As we now talk more and more about the fragmentation of zsmalloc. But >> >> we still need to manually add some debug code to see the fragmentation. >> >> So, I think we may add the statistics of memory fragmention in zsmalloc >> >> and disclose them to debugfs. Then we can easily get and analysis >> >> them when adding or developing new feature for zsmalloc. >> >> >> >> Below entries will be created when a zsmalloc pool is created: >> >> /sys/kernel/debug/zsmalloc/pool-n/obj_allocated >> >> /sys/kernel/debug/zsmalloc/pool-n/obj_used >> >> >> >> Then the status of objects usage will be: >> >> objects_usage = obj_used / obj_allocated >> >> >> > >> > I didn't look at the code in detail but It would be handy for developer >> > but not sure we should deliver it to admin so need configurable? >> What kind of configuration do you want? >> I think it is reasonable to expose such information to admin like >> */sys/kernel/debug/usb/device* >> >> Or maybe we can enclose these code by DEBUG macro which will be >> defined when CONFIG_ZSMALLOC_DEBUG is selected. > > Hmm, I'd like to separte DEBUG and STAT because we can add some > sanity checking(ex, poisoning for invalid overwriting or > handle<->obj mapping verification) with DEBUG while we could > count obj stat with STAT.
Yes. Add a CONFIG_ZSMALLOC_STAT will make code cleaner. > > So, now it seems you want CONFIG_ZSMALLOC_STAT? Yes, I will follow your suggestion. > >> >> > >> > How about making it per-sizeclass information, not per-pool? >> Yes, you are right. Per sizeclass information will be better for >> developers than per pool. >> >> Is it acceptable to show 256 lines like: >> #cat /sys/kernel/debug/zsmalloc/pool-1/obj_in_classes >> class obj_allocated obj_used >> 1 ... >> 2 ... >> .... >> .... >> 255 >> >> Anyway for developers, these information is more usefull. > > It would be better to show the number of pages so we can know > how many of fragment space in last subpage of zspage is wasted. > But I don't want to keep pages_used in memory but you could > calcurate it dynamically with obj_allocated when user access debugfs. > > #cat /sys/kernel/debug/zsmalloc/pool-1/obj_in_classes > class-size obj_allocated obj_used pages_used > 32 > 48 > . > . > . I got it. I will send a v2 patch. Thanks. > > Thanks! > > -- > Kind regards, > Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
