linux-kernel - Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

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:   Mon, 5 Sep 2016 12:59:08 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Hui Zhu <teawater@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Hui Zhu <zhuhui@...omi.com>, ngupta@...are.org,
        Hugh Dickins <hughd@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>, acme@...nel.org,
        alexander.shishkin@...ux.intel.com,
        Andrew Morton <akpm@...ux-foundation.org>, mhocko@...e.com,
        hannes@...xchg.org, mgorman@...hsingularity.net, vbabka@...e.cz,
        redkoi@...tuozzo.com, luto@...nel.org,
        kirill.shutemov@...ux.intel.com, geliangtang@....com,
        baiyaowei@...s.chinamobile.com, dan.j.williams@...el.com,
        vdavydov@...tuozzo.com, aarcange@...hat.com, dvlasenk@...hat.com,
        jmarchan@...hat.com, koct9i@...il.com, yang.shi@...aro.org,
        dave.hansen@...ux.intel.com, vkuznets@...hat.com,
        vitalywool@...il.com, ross.zwisler@...ux.intel.com,
        Thomas Gleixner <tglx@...utronix.de>,
        kwapulinski.piotr@...il.com, axboe@...com, mchristi@...hat.com,
        Joe Perches <joe@...ches.com>, namit@...are.com,
        Rik van Riel <riel@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

Hello,

On (09/05/16 11:18), Minchan Kim wrote:
[..]
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
> 
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
> memory compared to old so why does your patch decrease the number of
> lowmemory killing?

you are right Minchan, that was exactly my point. every compressed page
that does not end up in huge_object zspage should result in some memory
saving (somewhere in the range from bytes to kilobytes).

> A thing I can imagine is without this feature, zram could be full of
> uncompressible pages so good-compressible page cannot be swapped out.

a good theory.

in general, a selective compression of N first pages that fall under the
given compression limit is not the same as a selective compression of N
"best" compressible pages. so I'm a bit uncertain about the guarantees
that the patch can provide.

let's assume the following case.
- zram compression size limit set to 2400 bytes (only pages smaller than
  that will be stored in zsmalloc)
- first K pages to swapout have compression size of 2350 +/- 10%
- next L pages have compression size of 2500 +/- 10%
- last M pages are un-compressible - PAGE_SIZE.
- zram disksize can fit N pages
- N > K + L

so instead of compressing and swapping out K + L pages, you would compress
only K pages, leaving (L + M) * PAGE_SIZE untouched. thus I'd say that we
might have bigger chances of LMK/OOM/etc. in some cases.

	-ss