Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753504AbbEROky (ORCPT ); Mon, 18 May 2015 10:40:54 -0400 Received: from mail-pd0-f180.google.com ([209.85.192.180]:33975 "EHLO mail-pd0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752592AbbEROkv (ORCPT ); Mon, 18 May 2015 10:40:51 -0400 Date: Mon, 18 May 2015 23:40:27 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Karel Zak , Sergey Senozhatsky , linux-kernel@vger.kernel.org, util-linux@vger.kernel.org Subject: Re: what's cooking in zram for 4.1 Message-ID: <20150518144027.GA10979@swordfish> References: <20150509042148.GA514@swordfish> <20150511113833.GO27969@ws.net.home> <20150511115602.GA483@swordfish> <20150518135552.GA3270@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150518135552.GA3270@blaptop> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1390 Lines: 35 On (05/18/15 22:55), Minchan Kim wrote: > > > Why do you need all in one file? ... to provide consistent statistics? > > > > > > > yes, that's the main reason. > > In my side, other main reason was to reduce the number of system call > to see statistics. It is not only syscall overhead itself but also > causes slightly high-order allocation for kernel internal data structure > via slab allocation which is bad on low memory situation where is > frequent in zram-swap. Slab allocation could be fallback with 0-order > pages but it could cause excessive page reclaim seriously since compaction > didn't work. > Yes, it's a one of problem of current VM but there is no reason to hesitate > if we can avoid such problems and support consistent statistic as well. > true. syscalls and corresponding error handling for each one of them were on a list: https://www.marc.info/?l=linux-kernel&m=142586445420298&w=2 Karel has a remarkably good codebase, so error handling would not be an issue :-) that's why consistent stats moved forward. in general, increasing consistency and reducing the syscall pressure are good enough to move on. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/