[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1455764556-13979-1-git-send-email-sergey.senozhatsky@gmail.com>
Date: Thu, 18 Feb 2016 12:02:33 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Minchan Kim <minchan@...nel.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: [RFC PATCH 0/3] mm/zsmalloc: increase density and reduce memory wastage
Hello,
RFC
->huge classes are evil, and zsmalloc knows the watermark after which classes
are considered to be ->huge -- every object stored consumes the entire zspage
(which consist of a single order-0 page). zram, however, has its own statically
defined watermark for `bad' compression and stores every object larger than
this watermark as a PAGE_SIZE, object, IOW, to a ->huge class, this results
in increased memory consumption and memory wastage. And zram's 'bad' watermark
is much lower than zsmalloc. Apart from that, 'bad' compressions are not so rare,
on some of my tests 41% of writes result in 'bad' compressions.
This patch set inverts this 'huge class watermark' enforcement, it's zsmalloc
that knows better, not zram.
I did a number of tests (see 0003 commit message) and memory savings were around
36MB and 51MB (depending on zsmalloc configuration).
I also copied a linux-next directory (with object files, du -sh 2.5G)
and (ZS_MAX_PAGES_PER_ZSPAGE=5) memory saving were around 17-20MB.
Sergey Senozhatsky (3):
mm/zsmalloc: introduce zs_get_huge_class_size_watermark()
zram: use zs_get_huge_class_size_watermark()
mm/zsmalloc: change ZS_MAX_PAGES_PER_ZSPAGE
drivers/block/zram/zram_drv.c | 2 +-
drivers/block/zram/zram_drv.h | 6 ------
include/linux/zsmalloc.h | 2 ++
mm/zsmalloc.c | 21 +++++++++++++++++----
4 files changed, 20 insertions(+), 11 deletions(-)
--
2.7.1
Powered by blists - more mailing lists