From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752957AbbFRMOE (ORCPT ); Thu, 18 Jun 2015 08:14:04 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:35526 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751467AbbFRMN5 (ORCPT ); Thu, 18 Jun 2015 08:13:57 -0400 Date: Thu, 18 Jun 2015 21:13:14 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky , Sergey Senozhatsky Subject: Re: [RFC][PATCHv3 2/7] zsmalloc: partial page ordering within a fullness_list Message-ID: <20150618121314.GA518@swordfish> References: <1434628004-11144-1-git-send-email-sergey.senozhatsky@gmail.com> <1434628004-11144-3-git-send-email-sergey.senozhatsky@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1434628004-11144-3-git-send-email-sergey.senozhatsky@gmail.com> User-Agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Minchan, I didn't publish this patch separately yet, mostly to keep the discussion in on thread. If we decide that this patch is good enough, I'll resubmit it separately. I did some synthetic testing. And (not surprising at all) its not so clear. Any I used a modified zsmalloc debug stats (to also account and report ZS_FULL zspages). Automatic compaction was disabled. the results are: almost_full full almost_empty obj_allocated obj_used pages_used Base Total 3 163 25 2265 1691 302 Total 2 161 26 2297 1688 298 Total 2 145 27 2396 1701 311 Total 3 152 26 2364 1696 312 Total 3 162 25 2243 1701 302 Patched Total 3 155 22 2259 1691 293 Total 4 153 20 2177 1697 292 Total 2 157 23 2229 1696 298 Total 2 164 24 2242 1694 301 Total 2 159 24 2286 1696 301 Sooo... I don't know. The numbers are weird. On my x86_64 I saw somewhat lowered 'almost_empty', 'obj_allocated', 'obj_used', 'pages_used'. But it's a bit suspicious. The patch was not expected to dramatically improve things anyway. It's rather a theoretical improvement -- we sometimes keep busiest zspages first and, at the same time, we can re-use recently used zspages. I think it makes sense to also consider 'fullness_group fullness' in insert_zspage(). Unconditionally put ZS_ALMOST_FULL pages to list head, or (if zspage is !ZS_ALMOST_FULL) compage ->inuse. IOW, something like this --- mm/zsmalloc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 692b7dc..d576397 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -645,10 +645,11 @@ static void insert_zspage(struct page *page, struct size_class *class, * We want to see more ZS_FULL pages and less almost * empty/full. Put pages with higher ->inuse first. */ - if (page->inuse < (*head)->inuse) - list_add_tail(&page->lru, &(*head)->lru); - else + if (fullness == ZS_ALMOST_FULL || + (page->inuse >= (*head)->inuse)) list_add(&page->lru, &(*head)->lru); + else + list_add_tail(&page->lru, &(*head)->lru); } *head = page; --- test script modprobe zram echo 4 > /sys/block/zram0/max_comp_streams echo lzo > /sys/block/zram0/comp_algorithm echo 3g > /sys/block/zram0/disksize mkfs.ext4 /dev/zram0 mount -o relatime,defaults /dev/zram0 /zram cd /zram/ sync for i in {1..8192}; do dd if=/media/dump/down/zero_file of=/zram/$i iflag=direct bs=4K count=20 > /dev/null 2>&1 done sync head -n 1 /sys/kernel/debug/zsmalloc/zram0/classes tail -n 1 /sys/kernel/debug/zsmalloc/zram0/classes cd / umount /zram rmmod zram -ss