From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753020AbcBUR3Z (ORCPT ); Sun, 21 Feb 2016 12:29:25 -0500 Received: from mail-pf0-f172.google.com ([209.85.192.172]:34028 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751909AbcBUR3W (ORCPT ); Sun, 21 Feb 2016 12:29:22 -0500 From: Sergey Senozhatsky To: Minchan Kim Cc: Andrew Morton , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky , Sergey Senozhatsky Subject: [RFC][PATCH v2 0/3] mm/zsmalloc: increase objects density and reduce memory wastage Date: Sun, 21 Feb 2016 22:27:51 +0900 Message-Id: <1456061274-20059-1-git-send-email-sergey.senozhatsky@gmail.com> X-Mailer: git-send-email 2.7.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, RFC huge classes are evil. 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's one. Apart from that, 'bad' compressions are not so rare, on some of my tests 41% of writes are 'bad' compressions. This patch set inverts this 'huge class watermark' enforcement, it's zsmalloc that knows better, not zram. It also reduces the number of huge classes, this saves some memory. Since we request less pages for object larger than 3072 bytes, zmalloc in some cases should behave nicer when the system is getting low on free pages. Object's location is encoded as so mostly we have enough bits in OBJ_INDEX_BITS to increase ZS_MAX_ZSPAGE_ORDER and keep all of the classes. This is not true, however, on PAE/LPAE and PAGE_SHIFT 16 systems, so we need to preserve the exiting ZS_MAX_ZSPAGE_ORDER 2 limit there. Please commit 0003 for some numbers. Thanks to Joonsoo Kim for valuable questions and opinions. v2: -- keep ZS_MAX_PAGES_PER_ZSPAGE order of two (Joonsoo) -- suffice ZS_MIN_ALLOC_SIZE alignment requirement -- do not change ZS_MAX_PAGES_PER_ZSPAGE on PAE/LPAE and on PAGE_SHIFT 16 systems (Joonsoo) Sergey Senozhatsky (3): mm/zsmalloc: introduce zs_get_huge_class_size_watermark() zram: use zs_get_huge_class_size_watermark() mm/zsmalloc: increase 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 | 43 ++++++++++++++++++++++++++++++++++++------- 4 files changed, 39 insertions(+), 14 deletions(-) -- 2.7.1