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

Message-ID: <20181123062331.GA87907@google.com>
Date:   Fri, 23 Nov 2018 15:23:31 +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 03:59:26PM +0900, Sergey Senozhatsky wrote:
> On (11/22/18 15:31), Minchan Kim wrote:
> > > 
> > > I got what you mean now. Let's call it as "incompressible page wrieback"
> > > to prevent confusing.
> > > 
> > > "incompressible page writeback" would be orthgonal feature. The goal is
> > > "let's save memory at the cost of *latency*". If the page is swapped-in
> > > soon, it's unfortunate. However, the design expects once it's swapped out,
> > > it means it's non-workingset so soonish swappined-in would be rather not
> > > many, theoritically compared to other workingset.
> > > If's it's too frequent, it means system were heavily overcommitted.
> > 
> > Havid said, I agree it's not a good idea to enable incompressible page
> > writeback with idle page writeback. If you don't oppose, I want to add
> > new knob to "enable incompressible page writeback" so by default,
> > although we enable CONFIG_ZRAM_WRITEBACK, incompressible page writeback
> > is off until we enable the knob.
> > It would make some regressison if someone have used the feature but
> > I guess we are not too late.
> > 
> > What do you think?
> 
> Yes, totally works for me!
> 
> 
> "IDLE writeback" is superior to "incompressible writeback".
> 
> "incompressible writeback" is completely unpredictable and
> uncontrollable; it depens on data patterns and compression algorithms.
> While "IDLE writeback" is predictable.
> 
> I even suspect, that, *ideally*, we can remove "incompressible
> writeback". "IDLE pages" is a super set which also includes
> "incompressible" pages. So, technically, we still can do
> "incompressible writeback" from "IDLE writeback" path; but a much
> more reasonable one, based on a page idling period.
> 
> I understand that you want to keep "direct incompressible writeback"
> around. ZRAM is especially popular on devices which do suffer from
> flash wearout, so I can see "incompressible writeback" path becoming
> a dead code, long term.

Okay, both options makes regression if someone use it. Then, let's try
to remove it. It would make more clean with new idle writeback.

Thanks!