From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752535AbbFDH2F (ORCPT ); Thu, 4 Jun 2015 03:28:05 -0400 Received: from mail-pd0-f174.google.com ([209.85.192.174]:34710 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978AbbFDH1z (ORCPT ); Thu, 4 Jun 2015 03:27:55 -0400 Date: Thu, 4 Jun 2015 16:28:16 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 07/10] zsmalloc: introduce auto-compact support Message-ID: <20150604072816.GB662@swordfish> References: <1432911928-14654-1-git-send-email-sergey.senozhatsky@gmail.com> <1432911928-14654-8-git-send-email-sergey.senozhatsky@gmail.com> <20150604045725.GI2241@blaptop> <20150604053056.GA662@swordfish> <20150604062712.GJ2241@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150604062712.GJ2241@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 15:27), Minchan Kim wrote: [..] > > The problem is migration/freeing old zspage/allocating new zspage is > not a cheap, either. > If the system has no problem with small fragmented space, there is > no point to keep such overheads. > > So, ideal is we should trigger compaction once we realized system > is trouble but I don't have any good idea to detect it. > That's why i wanted to rely on the decision from user via > compact_threshold_ratio. that'll be extremly hard to understand knob. well, we can do something like -- don't let the number of "CLASS_ALMOST_EMPTY" to become N times greater than "CLASS_ALMOST_FULL". or -- don't let the number of pages in ZS_ALMOST_EMPTY pages to contribute 70% of class memory usage. that is 70% of all pages allocated for this class belong to ZS_ALMOST_EMPTY zspages, thus potentially we can compact it. > > > > > It's simple design of mm/compaction.c to prevent pointless overhead > > > but historically it made pains several times and required more > > > complicated logics but it's still painful. > > > > > > Other thing I found recently is that it's not always win zsmalloc > > > for zram is not fragmented. The fragmented space could be used > > > for storing upcoming compressed objects although it is wasted space > > > at the moment but if we don't have any hole(ie, fragment space) > > > via frequent compaction, zsmalloc should allocate a new zspage > > > which could be allocated on movable pageblock by fallback of > > > nonmovable pageblock request on highly memory pressure system > > > so it accelerates fragment problem of the system memory. > > > > yes, but compaction almost always leave classes fragmented. I think > > it's a corner case, when the number of unused allocated objects was > > exactly the same as the number of objects that we migrated and the > > number of migrated objects was exactly N*maxobj_per_zspage, so we > > left the class w/o any unused objects (OBJ_ALLOCATED == OBJ_USED). > > classes have 'holes' after compaction. > > > > > > > So, I want to pass the policy to userspace. > > > If we found it's really trobule on userspace, then, we need more > > > thinking. > > > > well, it can be under config "aggressive compaction" or "automatic > > compaction" option. > > > > If you really want to do it automatically without any feedback > form the userspace, we should find better algorithm. ok. I'll drop auto-compaction part for now and will resend general/minor zsmalloc tweaks today. -ss