From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752635AbbGJFVa (ORCPT ); Fri, 10 Jul 2015 01:21:30 -0400 Received: from mail-pd0-f177.google.com ([209.85.192.177]:34962 "EHLO mail-pd0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751729AbbGJFVX (ORCPT ); Fri, 10 Jul 2015 01:21:23 -0400 Date: Fri, 10 Jul 2015 14:21:13 +0900 From: Minchan Kim To: Sergey Senozhatsky Cc: Andrew Morton , Sergey Senozhatsky , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source Message-ID: <20150710052113.GA11329@bgram> References: <1436491929-6617-1-git-send-email-minchan@kernel.org> <20150710015828.GA692@swordfish> <20150710022910.GA18266@blaptop> <20150710041929.GC692@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150710041929.GC692@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 10, 2015 at 01:19:29PM +0900, Sergey Senozhatsky wrote: > On (07/10/15 11:29), Minchan Kim wrote: > > Good question. > > > > My worry was failure of order-0 page allocation in zram-swap path > > when memory presssure is really heavy but I didn't insist to you > > from sometime. The reason I changed my mind was > > > > 1. It's almost dead system if there is no order-0 page > > 2. If old might be working well, it's not our design, just luck. > > I mean I find your argument that some level of fragmentation > can be of use to be valid, to some degree. The benefit I had in mind was to prevent failure of allocation. > > > hm... by the way, > > unsigned long zs_malloc(struct zs_pool *pool, size_t size) > { > ... > size += ZS_HANDLE_SIZE; > class = pool->size_class[get_size_class_index(size)]; > ... > if (!first_page) { > spin_unlock(&class->lock); > first_page = alloc_zspage(class, pool->flags); > if (unlikely(!first_page)) { > free_handle(pool, handle); > return 0; > } > ... > > I'm thinking now, does it make sense to try harder here? if we > failed to alloc_zspage(), then may be we can try any of unused > objects from a 'upper' (larger/next) class? there might be a > plenty of them. I actually thought about that but I didn't have any report from community and product division of my compamy until now. But with auto-compaction, the chance would be higher than old so let's keep an eye on it(I think users can find it easily because swap layer emits "write write failure"). If it happens(ie, any report from someone), we could try to compact and then if it fails, we could fall back to upper class as a last resort. Thanks. > > -ss