From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932982AbcCOAx0 (ORCPT ); Mon, 14 Mar 2016 20:53:26 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:49512 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754429AbcCOAxY (ORCPT ); Mon, 14 Mar 2016 20:53:24 -0400 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.204 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Tue, 15 Mar 2016 09:54:14 +0900 From: Minchan Kim To: Sergey Senozhatsky CC: Sergey Senozhatsky , Andrew Morton , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH v3 3/5] mm/zsmalloc: introduce zs_huge_object() Message-ID: <20160315005414.GC19514@bbox> References: <1457016363-11339-1-git-send-email-sergey.senozhatsky@gmail.com> <1457016363-11339-4-git-send-email-sergey.senozhatsky@gmail.com> <20160314065331.GA12337@bbox> <20160314080842.GC542@swordfish> MIME-Version: 1.0 In-Reply-To: <20160314080842.GC542@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/03/15 09:53:21, Serialize by Router on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/03/15 09:53:21, Serialize complete at 2016/03/15 09:53:21 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 14, 2016 at 05:08:43PM +0900, Sergey Senozhatsky wrote: > On (03/14/16 15:53), Minchan Kim wrote: > [..] > > On Thu, Mar 03, 2016 at 11:46:01PM +0900, Sergey Senozhatsky wrote: > > > 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). On x86_64, PAGE_SHIFT 12 box, the > > > first non-huge class size is 3264, so starting down from size 3264, > > > objects share page(-s) and thus minimize memory wastage. > > > > > > zram, however, has its own statically defined watermark for `bad' > > > compression "3 * PAGE_SIZE / 4 = 3072", and stores every object > > > larger than this watermark (3072) as a PAGE_SIZE, object, IOW, > > > to a ->huge class, this results in increased memory consumption and > > > memory wastage. (With a small exception: 3264 bytes class. zs_malloc() > > > adds ZS_HANDLE_SIZE to the object's size, so some objects can pass > > > 3072 bytes and get_size_class_index(size) will return 3264 bytes size > > > class). > > > > > > Introduce zs_huge_object() function which tells whether the supplied > > > object's size belongs to a huge class; so zram now can store objects > > > to ->huge clases only when those objects have sizes greater than > > > huge_class_size_watermark. > > > > I understand the problem you pointed out but I don't like this way. > > > > Huge class is internal thing in zsmalloc so zram shouldn't be coupled > > with it. Zram uses just zsmalloc to minimize meory wastage which is > > all zram should know about zsmalloc. > > well, zram already coupled with zsmalloc() and it has always been, > that's the reality. there are zs_foo() calls, and not a single one > zpool_foo() call. I'm not in love with zs_huge_object() either, but > that's much better than forcing zsmalloc to be less efficient based > on some pretty random expectations (no offense). > > > Instead, how about changing max_zpage_size? > > > > static const size_t max_zpage_size = 4096; > > > > So, if compression doesn't help memory efficiency, we don't > > need to have decompress overhead. Only that case, we store > > decompressed page. > > hm, disabling this zram future entirely... this can do the trick, > I think. zswap is quite happy not having any expectations on > "how effectively an unknown compression algorithm will compress > an unknown data set", and that's the "right" thing to do here, > we can't count on anything. > > > > For other huge size class(e.g., PAGE_SIZE / 4 * 3 ~ PAGE_SIZE), > > you sent a patch to reduce waste memory as 5/5 so I think it's > > a good justification between memory efficiency VS. > > decompress overhead. > > so the plan is to raise max_zpage_size to PAGE_SIZE and to increase > the number of huge classes, so zsmalloc can be more helpful. sounds > good to me. nod. Thanks!