On Wed, Nov 28, 2018 at 03:41:41PM -0800, Andrew Morton wrote: > On Tue, 27 Nov 2018 14:54:29 +0900 Minchan Kim <minc...@kernel.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. "