From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753524AbbIQGV5 (ORCPT ); Thu, 17 Sep 2015 02:21:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:37709 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752696AbbIQGVz (ORCPT ); Thu, 17 Sep 2015 02:21:55 -0400 Subject: Re: [PATCH 0/3] allow zram to use zbud as underlying allocator To: Sergey Senozhatsky , Dan Streetman References: <20150914154901.92c5b7b24e15f04d8204de18@gmail.com> <55F6D356.5000106@suse.cz> <55F6D641.6010209@suse.cz> <20150915042216.GE1860@swordfish> Cc: Vitaly Wool , Minchan Kim , Sergey Senozhatsky , LKML , Linux-MM From: Vlastimil Babka Message-ID: <55FA5BFE.6010605@suse.cz> Date: Thu, 17 Sep 2015 08:21:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150915042216.GE1860@swordfish> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/15/2015 06:22 AM, Sergey Senozhatsky wrote: > On (09/15/15 00:08), Dan Streetman wrote: > [..] > > correct. a bit of internals: we don't scan all the zspages every > time. each class has stats for allocated used objects, allocated > used objects, etc. so we 'compact' only classes that can be > compacted: > > static unsigned long zs_can_compact(struct size_class *class) > { > unsigned long obj_wasted; > > obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) - > zs_stat_get(class, OBJ_USED); > > obj_wasted /= get_maxobj_per_zspage(class->size, > class->pages_per_zspage); > > return obj_wasted * class->pages_per_zspage; > } > > if we can free any zspages (which is at least one page), then we > attempt to do so. > > is compaction the root cause of the symptoms Vitaly observe? He mentioned the "compact_stalls" counter which in /proc/vmstat is for the traditional physical memory compaction, not the zsmalloc-specific one. Which would imply high-order allocations. Does zsmalloc try them first before falling back to the order-0 zspages linked together manually? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by kanga.kvack.org (Postfix) with ESMTP id EB0FC6B0038 for ; Thu, 17 Sep 2015 02:21:55 -0400 (EDT) Received: by lamp12 with SMTP id p12so4821698lam.0 for ; Wed, 16 Sep 2015 23:21:55 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id z5si1898884wiy.117.2015.09.16.23.21.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 23:21:54 -0700 (PDT) Subject: Re: [PATCH 0/3] allow zram to use zbud as underlying allocator References: <20150914154901.92c5b7b24e15f04d8204de18@gmail.com> <55F6D356.5000106@suse.cz> <55F6D641.6010209@suse.cz> <20150915042216.GE1860@swordfish> From: Vlastimil Babka Message-ID: <55FA5BFE.6010605@suse.cz> Date: Thu, 17 Sep 2015 08:21:50 +0200 MIME-Version: 1.0 In-Reply-To: <20150915042216.GE1860@swordfish> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Sergey Senozhatsky , Dan Streetman Cc: Vitaly Wool , Minchan Kim , Sergey Senozhatsky , LKML , Linux-MM On 09/15/2015 06:22 AM, Sergey Senozhatsky wrote: > On (09/15/15 00:08), Dan Streetman wrote: > [..] > > correct. a bit of internals: we don't scan all the zspages every > time. each class has stats for allocated used objects, allocated > used objects, etc. so we 'compact' only classes that can be > compacted: > > static unsigned long zs_can_compact(struct size_class *class) > { > unsigned long obj_wasted; > > obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) - > zs_stat_get(class, OBJ_USED); > > obj_wasted /= get_maxobj_per_zspage(class->size, > class->pages_per_zspage); > > return obj_wasted * class->pages_per_zspage; > } > > if we can free any zspages (which is at least one page), then we > attempt to do so. > > is compaction the root cause of the symptoms Vitaly observe? He mentioned the "compact_stalls" counter which in /proc/vmstat is for the traditional physical memory compaction, not the zsmalloc-specific one. Which would imply high-order allocations. Does zsmalloc try them first before falling back to the order-0 zspages linked together manually? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org