On Mon, Mar 09, 2015 at 09:57:18AM +0900, Sergey Senozhatsky wrote: > On (03/09/15 09:49), Minchan Kim wrote: > > > rather a discussion question. > > > > > > Minchan, do you want to provide num_migrated as part of zsmalloc stats > > > rather > > > than having yet another zram attr? we already provide zsmalloc stats and > > > this > > > type of information seems to belong there. just idea. > > > > Hmm, CONFIG_ZSMALLOC_STAT is actually to show zsmalloc internals. > > well, to be fair, compaction is a zsmalloc internal. zram has nothing to do > with > it. > > but do we we even need this stat? it seems that > > mem_total_used (before compaction) - mem_total_user (after comapction) > > will give user an idea on how much memory was compacted.
It's not enough. What I want to know is compaction efficiency per client of zsmalloc(ie, zram). IOW, (how many of freed pages / how many of objects) per zs_compact. > > -ss > > > That's why it is on debugfs. If we add the stat into zsmalloc, we should > > turn on debugfs > > and CONFIG_ZSMALLOC_STAT to see *a* stat. Even, CONFIG_ZSMALLOC_STAT will > > add > > unncessary overheads to account another stats fo zsmalloc internals. > > > > As well, if we add auto-compacion like stuff in zsmalloc(ie, it will trigger > > by itself if fragmention is over to predefined theshold), the stat will > > accumulate stat while someone want to see snapshot compaction effiecieny > > of the moment. > > > > So, I want to keep it in zram now. > > > > -- > > Kind regards, > > Minchan Kim > > -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
