From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751370AbcEMHjf (ORCPT ); Fri, 13 May 2016 03:39:35 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:36828 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbcEMHje (ORCPT ); Fri, 13 May 2016 03:39:34 -0400 Date: Fri, 13 May 2016 16:41:05 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] zram: introduce per-device debug_stat sysfs node Message-ID: <20160513074105.GD615@swordfish> References: <20160511134553.12655-1-sergey.senozhatsky@gmail.com> <20160512234143.GA27204@bbox> <20160513010929.GA615@swordfish> <20160513062303.GA21204@bbox> <20160513065805.GB615@swordfish> <20160513070553.GC615@swordfish> <20160513072006.GA21484@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160513072006.GA21484@bbox> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (05/13/16 16:20), Minchan Kim wrote: [..] > > here I assume that the biggest contributor to re-compress latency is > > enabled preemption after zcomp_strm_release() and this second zs_malloc(). > > the compression itself of a PAGE_SIZE buffer should be fast enough. so IOW > > we would pass down the slow path, but would not account it. > > biggest contributors are 1. direct reclaim by second zsmalloc call + > 2. recompression overhead. 3. enabled preemption after zcomp_strm_release() we can be scheduled out for a long time. > If zram start to support high comp ratio but slow speed algorithm like zlib > 2 might be higher than 1 in the future so let's not ignore 2 overhead. hm, yes, good point. not arguing, just for notice -- 2) has an upper limit on its complexity, because we basically just do a number of arithmetical operations on a buffer that has upper size limit -- PAGE_SIZE; while reclaim in zsmalloc() can last an arbitrary amount of time. that's why I tend to think of a PAGE_SIZE compression contribution as of constant, that can be ignored. > Although 2 is smaller, your patch just accounts only direct reclaim but my > suggestion can count both 1 and 2 so isn't it better? > > I don't know why it's arguable here. :) no objections to put it next to goto. just making sure that we have considered all the possibilities and cases. will resend shortly, thanks! -ss