linux-kernel - Re: [PATCH 4/6] zram: support idle page writeback

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]

Message-ID: <20181122050437.GA182024@google.com>
Date:   Thu, 22 Nov 2018 14:04:37 +0900
From:   Minchan Kim <minchan@...nel.org>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] zram: support idle page writeback

On Thu, Nov 22, 2018 at 11:14:43AM +0900, Sergey Senozhatsky wrote:
> On (11/21/18 05:34), Minchan Kim wrote:
> > > 
> > > Just a thought,
> > > 
> > > I wonder if it will make sense (and if it will be possible) to writeback
> > > idle _compressed_ objects. Right now we decompress, say, a perfectly
> > > fine 400-byte compressed object to a PAGE_SIZE-d object and then push
> > > it to the WB device. In this particular case it has a x10 bigger IO
> > > pressure on flash. If we can write/read compressed object then we
> > > will write and read 400-bytes, instead of PAGE_SIZE.
> > 
> > Although it has pros/cons, that's the my final goal although it would
> > add much complicated stuffs. Sometime, we should have the feature.
> 
> So you plan to switch to "compressed objects" writeback?

No switch. I want both finally. There are pros and cons.
Compressible write would be good for wearout of flash device(that's I want
to have it) but it has several read of a block(since the block has several
zpage) and decompression latency as well as complicated logic of management
of block. That's the unnecessary thing If backing device or system doesn't
have wearout concern.

> 
> > However, I want to go simple one first which is very valuable, too.
> 
> Flash wearout is a serious problem; maybe less of a problem on smart
> phones, but much bigger on TVs and on other embedded devices that have
> lifespans of 5+ years. With "writeback idle compressed" we can remove

Yub, It's a serious. That's why my patchset has writeback limitation,
stats as well as idle marking to help the system design.

> the existing "writeback incompressible pages" and writeback only
> "idle, compressed" pages.
> 
> The existing incompressible writeback is way too aggressive, and,

Do not agree. It depends on the system design.
Think idle page writeback. Once a day, you write out idle pages.
As a inital stage, you could write every idle pages into the storage.
it could be several hundred MB and next day? there is few MB write
because every idle pages were stored yesterday.
Even, we have a write_limit. You could estimate how per-day write
can demage your system. Your daemon can see one a day and decide
further write or not.

> additionally, it's too simple. It writes-back pages which can be
> swapped in immediately; which basically means that we do pointless
> PAGE_SIZE writes to a device which doesn't really like pointless
> writes.

This patchset aims for *IDLE page* writeback and you can define
what is IDLE page by yourself. It doesn't do pointless writeback.

> 
> It's a whole different story with idle, compressible pages writeback.

I don't understand your point.

> 
> 	-ss