Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934519AbdHYVQl (ORCPT ); Fri, 25 Aug 2017 17:16:41 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48606 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932374AbdHYVQj (ORCPT ); Fri, 25 Aug 2017 17:16:39 -0400 Date: Fri, 25 Aug 2017 14:16:37 -0700 From: Andrew Morton To: Michal Hocko Cc: Tim Murray , Sonny Rao , Daniel Colascione , Minchan Kim , "linux-kernel@vger.kernel.org" , Joel Fernandes , Al Viro , linux-fsdevel@vger.kernel.org, Linux-MM , Robert Foss , linux-api@vger.kernel.org, Luigi Semenzato Subject: Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup Message-Id: <20170825141637.f11a36a9997b4b705d5b6481@linux-foundation.org> In-Reply-To: <20170824085553.GB5943@dhcp22.suse.cz> References: <20170808132554.141143-1-dancol@google.com> <20170810001557.147285-1-dancol@google.com> <20170810043831.GB2249@bbox> <20170810084617.GI23863@dhcp22.suse.cz> <20170810105852.GM23863@dhcp22.suse.cz> <20170824085553.GB5943@dhcp22.suse.cz> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1135 Lines: 25 On Thu, 24 Aug 2017 10:55:53 +0200 Michal Hocko wrote: > > If we assume that the number of VMAs is going to increase over time, > > then doing anything we can do to reduce the overhead of each VMA > > during PSS collection seems like the right way to go, and that means > > outputting an aggregate statistic (to avoid whatever overhead there is > > per line in writing smaps and in reading each line from userspace). > > > > Also, Dan sent me some numbers from his benchmark measuring PSS on > > system_server (the big Android process) using smaps vs smaps_rollup: > > > > using smaps: > > iterations:1000 pid:1163 pss:220023808 > > 0m29.46s real 0m08.28s user 0m20.98s system > > > > using smaps_rollup: > > iterations:1000 pid:1163 pss:220702720 > > 0m04.39s real 0m00.03s user 0m04.31s system > > I would assume we would do all we can to reduce this kernel->user > overhead first before considering a new user visible file. I haven't > seen any attempts except from the low hanging fruid I have tried. It's hard to believe that we'll get anything like a 5x speedup via optimization of the existing code?