Re: [PATCH 2/2] zram: gather statistics in a unique file
From: Nitin Gupta
Date: Mon Feb 11 2013 - 13:50:55 EST
On 02/11/2013 10:16 AM, Greg Kroah-Hartman wrote:
On Mon, Feb 11, 2013 at 10:07:45AM -0800, Davidlohr Bueso wrote:
On Sun, 2013-02-10 at 21:41 -0800, Greg Kroah-Hartman wrote:
On Sun, Feb 10, 2013 at 08:29:06PM -0800, Davidlohr Bueso wrote:
Instead of having one sysfs file per zram statistic, group them all
in a single, reader-friendly, 'statistics' file. This not only reduces
code but is also makes it easier to visualize. The new file looks like:
Number of reads: 24
Number of writes: 1055
Invalid IO: 0
Notify free: 0
Zero pages: 1042
Orig data size: 49152 bytes
Compressed data: 838 bytes
Total memory used: 53248 bytes
Signed-off-by: Davidlohr Bueso <davidlohr.bueso@xxxxxx>
No, please, the rule for sysfs is "one value per file", not files with
lots of data that you need to parse.
If you want to do something like this, then do it in debugfs, but NEVER
So, you would you be open to having the statistics file in debugfs and
removing the individual files sysfs?
If these are merely debugging information, they should go to debugfs.
If they are something that all users need/want, they should stay in
These zram statistics should stay in sysfs.
These stats could be used by userspace programs to trigger different
actions. For instance, defrag%, calculated using compressed size and
actual memory used, could be used to trigger defrag (not yet
implemented). Or low hit rates [number of reads/number of writes] is
useful in determining is zram is really helpful or not, in case it's
being used as swap. If not, zram should be unloaded or reset to save
Other than this, plain compression ratio stats along with zero_pages are
also useful and not really debug info.
Though stats are spread across many files, it's easy to script them into
a single view:
I use this script to gather and display stats for each active zram device.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/