From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754673AbcEYFOZ (ORCPT <rfc822;w@1wt.eu>);
	Wed, 25 May 2016 01:14:25 -0400
Received: from LGEAMRELO13.lge.com ([156.147.23.53]:49793 "EHLO
	lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751545AbcEYFOX (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 25 May 2016 01:14:23 -0400
X-Original-SENDERIP: 156.147.1.121
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: Wed, 25 May 2016 14:14:38 +0900
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCH v6 11/12] zsmalloc: page migration support
Message-ID: <20160525051438.GA14786@bbox>
References: <1463754225-31311-1-git-send-email-minchan@kernel.org>
 <1463754225-31311-12-git-send-email-minchan@kernel.org>
 <20160524052824.GA496@swordfish>
 <20160524062801.GB29094@bbox>
MIME-Version: 1.0
In-Reply-To: <20160524062801.GB29094@bbox>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November
 21, 2013) at 2016/05/25 14:14:20,
	Serialize by Router on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November
 21, 2013) at 2016/05/25 14:14:20,
	Serialize complete at 2016/05/25 14:14:20
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello Sergey,

On Tue, May 24, 2016 at 03:28:01PM +0900, Minchan Kim wrote:
<snip>

> > hm... zsmalloc is getting sooo complex now.
> > 
> > `system_wq' -- can we have problems here when the system is getting
> > low on memory and workers are getting increasingly busy trying to
> > allocate the memory for some other purposes?
> > 
> > _theoretically_ zsmalloc can stack a number of ready-to-release zspages,
> > which won't be accessible to zsmalloc, nor will they be released. how likely
> > is this? hm, can zsmalloc take zspages from that deferred release list when
> > it wants to allocate a new zspage?
> 
> Done.
> 
> > 
> > do you also want to kick the deferred page release from the shrinker
> > callback, for example?
> 
> Yeb, it can be. I will do it at next revision. :)
> Thanks!
> 

I tried it now but I feel strongly we want to fix shrinker first.
Now, shrinker doesn't consider VM's request(i.e., sc->nr_to_scan) but
shrink all objects which could make latency huge.

I want to fix it as another issue and then adding ZS_EMPTY pool pages
purging logic based on it because many works for zsmalloc stucked
with this patchset now which churns old code heavily. :(