From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754429AbcIED7E (ORCPT ); Sun, 4 Sep 2016 23:59:04 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:35603 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754193AbcIED7A (ORCPT ); Sun, 4 Sep 2016 23:59:00 -0400 Date: Mon, 5 Sep 2016 12:59:08 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Hui Zhu , Sergey Senozhatsky , Hui Zhu , ngupta@vflare.org, Hugh Dickins , Steven Rostedt , Ingo Molnar , Peter Zijlstra , acme@kernel.org, alexander.shishkin@linux.intel.com, Andrew Morton , mhocko@suse.com, hannes@cmpxchg.org, mgorman@techsingularity.net, vbabka@suse.cz, redkoi@virtuozzo.com, luto@kernel.org, kirill.shutemov@linux.intel.com, geliangtang@163.com, baiyaowei@cmss.chinamobile.com, dan.j.williams@intel.com, vdavydov@virtuozzo.com, aarcange@redhat.com, dvlasenk@redhat.com, jmarchan@redhat.com, koct9i@gmail.com, yang.shi@linaro.org, dave.hansen@linux.intel.com, vkuznets@redhat.com, vitalywool@gmail.com, ross.zwisler@linux.intel.com, Thomas Gleixner , kwapulinski.piotr@gmail.com, axboe@fb.com, mchristi@redhat.com, Joe Perches , namit@vmware.com, Rik van Riel , "linux-kernel@vger.kernel.org" , Linux Memory Management List Subject: Re: [RFC 0/4] ZRAM: make it just store the high compression rate page Message-ID: <20160905035908.GA552@swordfish> References: <1471854309-30414-1-git-send-email-zhuhui@xiaomi.com> <20160825060957.GA568@swordfish> <20160905021852.GB22701@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160905021852.GB22701@bbox> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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