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

[Minchan Kim]

Hello Hui,

On Mon, Aug 22, 2016 at 04:25:05PM +0800, Hui Zhu wrote:
> Current ZRAM just can store all pages even if the compression rate
> of a page is really low.  So the compression rate of ZRAM is out of
> control when it is running.
> In my part, I did some test and record with ZRAM.  The compression rate
> is about 40%.
> 
> This series of patches make ZRAM can just store the page that the
> compressed size is smaller than a value.
> With these patches, I set the value to 2048 and did the same test with
> before.  The compression rate is about 20%.  The times of lowmemorykiller
> also decreased.
> 
> Hui Zhu (4):
> vmscan.c: shrink_page_list: unmap anon pages after pageout
> Add non-swap page flag to mark a page will not swap
> ZRAM: do not swap the pages that compressed size bigger than non_swap
> vmscan.c: zram: add non swap support for shmem file pages
> 
>  drivers/block/zram/Kconfig     |   11 +++
>  drivers/block/zram/zram_drv.c  |   38 +++++++++++
>  drivers/block/zram/zram_drv.h  |    4 +
>  fs/proc/meminfo.c              |    6 +
>  include/linux/mm_inline.h      |   20 +++++
>  include/linux/mmzone.h         |    3 
>  include/linux/page-flags.h     |    8 ++
>  include/linux/rmap.h           |    5 +
>  include/linux/shmem_fs.h       |    6 +
>  include/trace/events/mmflags.h |    9 ++
>  kernel/events/uprobes.c        |   16 ++++
>  mm/Kconfig                     |    9 ++
>  mm/memory.c                    |   34 ++++++++++
>  mm/migrate.c                   |    4 +
>  mm/mprotect.c                  |    8 ++
>  mm/page_io.c                   |   11 ++-
>  mm/rmap.c                      |   23 ++++++
>  mm/shmem.c                     |   77 +++++++++++++++++-----
>  mm/vmscan.c                    |  139 +++++++++++++++++++++++++++++++++++------
>  19 files changed, 387 insertions(+), 44 deletions(-)

I look over the patchset now and I feel it's really hard to accept
in mainline, unfortunately. Sorry.
It spreads out lots of tricky code in MM for a special usecase
so it's hard to justify, I think.

A thing I can think to avoid no-good-comp-ratio page storing into zram
is that zram can return AOP_WRITEPAGE_ACTIVATE if it found the page is
uncompressible in zram_rw_page so that VM can promote the page to
active LRU. With that, the uncompressible page will have more time to
redirty with hope that it can have compressible data this time.