From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751526AbcEMHTf (ORCPT ); Fri, 13 May 2016 03:19:35 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:58731 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbcEMHTe (ORCPT ); Fri, 13 May 2016 03:19:34 -0400 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.150 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 13 May 2016 16:20:06 +0900 From: Minchan Kim To: Sergey Senozhatsky CC: Sergey Senozhatsky , Andrew Morton , , Subject: Re: [PATCH] zram: introduce per-device debug_stat sysfs node Message-ID: <20160513072006.GA21484@bbox> References: <20160511134553.12655-1-sergey.senozhatsky@gmail.com> <20160512234143.GA27204@bbox> <20160513010929.GA615@swordfish> <20160513062303.GA21204@bbox> <20160513065805.GB615@swordfish> <20160513070553.GC615@swordfish> MIME-Version: 1.0 In-Reply-To: <20160513070553.GC615@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB08/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/05/13 16:19:31, Serialize by Router on LGEKRMHUB08/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/05/13 16:19:31, Serialize complete at 2016/05/13 16:19:31 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 13, 2016 at 04:05:53PM +0900, Sergey Senozhatsky wrote: > On (05/13/16 15:58), Sergey Senozhatsky wrote: > > On (05/13/16 15:23), Minchan Kim wrote: > > [..] > > > @@ -737,12 +737,12 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > > > zcomp_strm_release(zram->comp, zstrm); > > > zstrm = NULL; > > > > > > - atomic64_inc(&zram->stats.num_recompress); > > > - > > > handle = zs_malloc(meta->mem_pool, clen, > > > GFP_NOIO | __GFP_HIGHMEM); > > > - if (handle) > > > + if (handle) { > > > + atomic64_inc(&zram->stats.num_recompress); > > > goto compress_again; > > > + } > > > > not like a real concern... > > > > the main (and only) purpose of num_recompress is to match performance > > slowdowns and failed fast write paths (when the first zs_malloc() fails). > > this matching is depending on successful second zs_malloc(), but if it's > > also unsuccessful we would only increase failed_writes; w/o increasing > > the failed fast write counter, while we actually would have failed fast > > write and extra zs_malloc() [unaccounted in this case]. yet it's probably > > a bit unlikely to happen, but still. well, just saying. > > 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. 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. 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. :) > > -ss > > -- > 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