From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751809AbbFDDbG (ORCPT ); Wed, 3 Jun 2015 23:31:06 -0400 Received: from mail-pd0-f171.google.com ([209.85.192.171]:35254 "EHLO mail-pd0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbbFDDaz (ORCPT ); Wed, 3 Jun 2015 23:30:55 -0400 Date: Thu, 4 Jun 2015 12:31:18 +0900 From: Sergey Senozhatsky To: Sergey Senozhatsky Cc: Minchan Kim , Sergey Senozhatsky , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 03/10] zsmalloc: introduce zs_can_compact() function Message-ID: <20150604033118.GG1951@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> <20150604031514.GE1951@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150604031514.GE1951@swordfish> 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 12:15), Sergey Senozhatsky wrote: > 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. > so what I'm thinking of right now, is: -- first do "if we have enough free objects to free at least one page" check. compact if true. -- if false, then we can do on a per-page basis "if page->inuse <= class free-objs capacity" then compact it, else select next almost_empty page. here would be helpful to have pages ordered by ->inuse. but this is far to expensive. I have a patch that I will post later that introduces weak/partial page ordering within fullness_list (really inexpensive: just one int compare to add a page with a higher ->inuse to list head instead of list tail). -ss