linux-kernel - Re: [RFC PATCH V2] zram:calculate available memory when zram is used

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:   Sun, 6 Jun 2021 12:45:46 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Greg KH <gregkh@...uxfoundation.org>, yongw.pur@...il.com
Cc:     minchan@...nel.org, ngupta@...are.org, senozhatsky@...omium.org,
        axboe@...nel.dk, akpm@...ux-foundation.org,
        songmuchun@...edance.com, linux-kernel@...r.kernel.org,
        linux-block@...r.kernel.org, linux-mm@...ck.org,
        willy@...radead.org, linux-api@...r.kernel.org
Subject: Re: [RFC PATCH V2] zram:calculate available memory when zram is used

On 05.06.21 19:07, Greg KH wrote:
> On Sat, Jun 05, 2021 at 09:24:00AM -0700, yongw.pur@...il.com wrote:
>> From: wangyong <yongw.pur@...il.com>
>>
>> When zram is used, available+Swap free memory is obviously
>> bigger than we actually can use, because zram can compress
>> memory by compression algorithm and zram compressed data
>> will occupy memory too.
>>
>> So, we can count the compression ratio of zram in the kernel.
>> The space will be saved by zram and other swap device are
>> calculated as follows:
>> zram[swapfree - swapfree * compress ratio] + swapdev[swapfree]
>> We can evaluate the available memory of the whole system as:
>> MemAvailable+zram[swapfree - swapfree * compress ratio]+swapdev[swapfree]
>>
>> Add an entry to the /proc/meminfo file, returns swap will save space.
>> Which name is more appropriate is still under consideration.
>> There are several alternative names: SwapAvailable, SwapSaved,
>> SwapCompressible
>>
>> Signed-off-by: wangyong <yongw.pur@...il.com>
>> ---
>>   drivers/block/zram/zcomp.h    |  1 +
>>   drivers/block/zram/zram_drv.c | 19 +++++++++
>>   drivers/block/zram/zram_drv.h |  1 +
>>   fs/proc/meminfo.c             |  1 +
>>   include/linux/swap.h          | 10 +++++
>>   mm/swapfile.c                 | 95 +++++++++++++++++++++++++++++++++++++++++++
>>   mm/vmscan.c                   |  1 +
>>   7 files changed, 128 insertions(+)
> 
> You are adding a new sysfs file with no new Documentation/ABI entry.

Indeed. And in the best case, the change would be accompanied with a man 
page update patch for the "proc" man page.

> Also are you sure you are allowed to add a new proc file entry without
> breaking existing tools?

I think adding new entries is not a problem. Parsers have to deal with 
new entries popping up. For example, we introduced "ShadowCallStack:" in 
2020 via 628d06a48f57 ("scs: Add page accounting for shadow call stack 
allocations").


-- 
Thanks,

David / dhildenb