From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751828AbbFDDO6 (ORCPT ); Wed, 3 Jun 2015 23:14:58 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:33793 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751404AbbFDDOv (ORCPT ); Wed, 3 Jun 2015 23:14:51 -0400 Date: Thu, 4 Jun 2015 12:15:14 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCH 03/10] zsmalloc: introduce zs_can_compact() function Message-ID: <20150604031514.GE1951@swordfish> References: <1432911928-14654-1-git-send-email-sergey.senozhatsky@gmail.com> <1432911928-14654-4-git-send-email-sergey.senozhatsky@gmail.com> <20150604025533.GE2241@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150604025533.GE2241@blaptop> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (06/04/15 11:55), Minchan Kim wrote: > > [ 3303.108960] class-3072 objs:24652 inuse:24628 objs-per-page:4 pages-tofree:6 > > maxobjs-per-zspage? > yeah, I shortened it to be more of less "80 chars" friendly. [..] > > + * calculate how many unused allocated objects we > > c should be captital. > > I hope you will fix all of english grammer in next spin > because someone(like me) who is not a native will learn the > wrong english. :) sure, will fix. yeah, I'm a native broken english speaker :-) > > + * have and see if we can free any zspages. otherwise, > > + * compaction can just move objects back and forth w/o > > + * any memory gain. > > + */ > > + unsigned long ret = zs_stat_get(class, OBJ_ALLOCATED) - > > + zs_stat_get(class, OBJ_USED); > > + > > I prefer obj_wasted to "ret". ok. I'm still thinking how good it should be. for automatic compaction we don't want to uselessly move objects between pages and I tend to think that it's better to compact less, than to waste more cpu cycless. on the other hand, this policy will miss cases like: -- free objects in class: 5 (free-objs class capacity) -- page1: inuse 2 -- page2: inuse 2 -- page3: inuse 3 -- page4: inuse 2 so total "insuse" is greater than free-objs class capacity. but, it's surely possible to compact this class. partial inuse summ <= free-objs class capacity (a partial summ is a ->inuse summ of any two of class pages: page1 + page2, page2 + page3, etc.). otoh, these partial sums will badly affect performance. may be for automatic compaction (the one that happens w/o user interaction) we can do zs_can_compact() and for manual compaction (the one that has been triggered by a user) we can old "full-scan". anyway, zs_can_compact() looks like something that we can optimize independently later. -ss > > + ret /= get_maxobj_per_zspage(class->size, > > + class->pages_per_zspage); > > + return ret > 0; > > +} > > + > > static unsigned long __zs_compact(struct zs_pool *pool, > > struct size_class *class) > > { > > @@ -1686,6 +1708,9 @@ static unsigned long __zs_compact(struct zs_pool *pool, > > > > BUG_ON(!is_first_page(src_page)); > > > > + if (!zs_can_compact(class)) > > + break; > > + > > cc.index = 0; > > cc.s_page = src_page; > > > > -- > > 2.4.2.337.gfae46aa > > > > -- > Kind regards, > Minchan Kim >