linux-kernel - Re: [PATCH 2/2] zram: gather statistics in a unique file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 11 Feb 2013 10:50:46 -0800
From:	Nitin Gupta <ngupta@...are.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	Davidlohr Bueso <davidlohr.bueso@...com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] zram: gather statistics in a unique file

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@...com>
>>>
>>> No, please, the rule for sysfs is "one value per file", not files with
>>> lots of data that you need to parse.
>>
>> Ok.
>>
>>>
>>> If you want to do something like this, then do it in debugfs, but NEVER
>>> in sysfs.
>>
>> 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
> sysfs as-is.
>

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 
memory space.

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:

http://compcache.googlecode.com/git/sub-projects/scripts/zram_stats

I use this script to gather and display stats for each active zram device.

Thanks,
Nitin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/