linux-kernel - Re: [PATCH v3 7/7] zram: writeback throttle

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Nov 2018 10:55:54 +0900
From:   Minchan Kim <minchan@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Joey Pabalinas <joeypabalinas@...il.com>
Subject: Re: [PATCH v3 7/7] zram: writeback throttle

On Wed, Nov 28, 2018 at 03:41:41PM -0800, Andrew Morton wrote:
> On Tue, 27 Nov 2018 14:54:29 +0900 Minchan Kim <minchan@...nel.org> wrote:
> 
> > On small memory system, there are lots of write IO so if we use
> > flash device as swap, there would be serious flash wearout.
> > To overcome the problem, system developers need to design write
> > limitation strategy to guarantee flash health for entire product life.
> > 
> > This patch creates a new konb "writeback_limit" on zram. With that,
> > if current writeback IO count(/sys/block/zramX/io_stat) excceds

						   bd_stat

> > the limitation, zram stops further writeback until admin can reset
> > the limit.
> 
> I'm not really understanding this.  Does this only refer to suspending
> the idle page writeback feature?  Not all zram writeback, surely?

It aims for all zram writeback.

> 
> I don't think the documentation gives an administrator sufficient
> information to effectively use the feature.  Some additional discussion
> would help.  What sort of values should it be set to and why?
> 
> And what is the default setting?  And why?

Default setting is 0 so there is no limitation because we couldn't
expect user's workload of zram.

> 
> And the limit isn't persistent across reboots which makes me wonder
> whether the overall feature is particularly valuable?

Good point.
Keeping the value in persisten across reboot is userspace's role.

I will add this for admin
"
You could know how many of write happens since the system boot
via /sys/block/zramX/bd_stat's bd_writes.
If your backing device has wearout concern, you could limit the
writing via /sys/block/zramX/writeback_limit.

For instance, if the vaule you read bd_writes is 200, you could
set 300 to writeback_limit so upcomding 100 write be only allowed.
If you set the writeback_limit to lower value than current
bd_writes's value, zram allow further writeback without limit.

The value will reset when your system reboot so keeping how many
write happn until now across reboot is user's job.
"