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: <20181122063103.GB211816@google.com>
Date:   Thu, 22 Nov 2018 15:31:03 +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:15:42PM +0900, Minchan Kim wrote:
> On Thu, Nov 22, 2018 at 02:40:40PM +0900, Sergey Senozhatsky wrote:
> > On (11/22/18 14:04), Minchan Kim wrote:
> > > 
> > > > 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.
> > 
> > Seems you misunderstood me. I'm not saying that IDLE writeback is bad.
> > On the contrary, I think IDLE writeback is x100 better than writeback
> > which we currently have.
> > 
> > The "pointless writeback" comment was about the existing writeback,
> > when we WB pages which we couldn't compress. We can have a relative
> > huge percentage of incompressible pages, and not all of them will end
> > up being IDLE:
> >  - we swap out page
> >  - can't compress it
> >  - writeback PAGE_SIZE
> >  - swap it in two seconds later
> 
> 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?