From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752746AbbCJKry (ORCPT ); Tue, 10 Mar 2015 06:47:54 -0400 Received: from mail-la0-f48.google.com ([209.85.215.48]:41032 "EHLO mail-la0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752205AbbCJKrv (ORCPT ); Tue, 10 Mar 2015 06:47:51 -0400 From: Rasmus Villemoes To: Tejun Heo Cc: Joe Perches , linux-kernel@vger.kernel.org, "Peter Zijlstra \(Intel\)" , Andrew Morton Subject: Re: [RFC] lib/vsprintf.c: Even faster decimal conversion Organization: D03 References: <1424476281-26873-1-git-send-email-linux@rasmusvillemoes.dk> <87r3t3eafm.fsf@rasmusvillemoes.dk> <1425571413.31859.1.camel@perches.com> <20150305161051.GE23912@htj.duckdns.org> <87egp384m0.fsf@rasmusvillemoes.dk> X-Hashcash: 1:20:150310:linux-kernel@vger.kernel.org::3MGt4ETAMa8cRX94:0000000000000000000000000000000000q5j X-Hashcash: 1:20:150310:peterz@infradead.org::oYJpZfp2VrkL4Qqx:000000000000000000000000000000000000000000j+p X-Hashcash: 1:20:150310:joe@perches.com::TFxd5nDQtXWbwdeg:001HWG X-Hashcash: 1:20:150310:tj@kernel.org::1647hqKLhQzkpVBB:00001k6D X-Hashcash: 1:20:150310:akpm@linux-foundation.org::abIrKe8AM56oP5tl:0000000000000000000000000000000000007yWE Date: Tue, 10 Mar 2015 11:47:47 +0100 In-Reply-To: <87egp384m0.fsf@rasmusvillemoes.dk> (Rasmus Villemoes's message of "Thu, 05 Mar 2015 23:24:39 +0100") Message-ID: <87zj7l6sdo.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 05 2015, Rasmus Villemoes wrote: > On Thu, Mar 05 2015, Tejun Heo wrote: > >> I'd like to see how this actually affects larger operations - sth >> along the line of top consumes D% less CPU cycles w/ N processes - if >> for nothing else, just to get the sense of scale, > > That makes sense. I'll see if I can get some reproducible numbers, but > I'm afraid the effect drowns in all the syscall overhead. Which would be > a valid argument against touching the code. I wasn't able to come up with a way to measure the absolute %cpu reliably enough (neither from top's own output or using something like watch -n1 ps -p $toppid -o %cpu) - it fluctuates too much to see any difference. But using perf I was able to get somewhat stable numbers, which suggest an improvement in the 0.5-1.0% range [1]. Measured with 10000 [2] sleeping processes in an idle virtual machine (and on mostly idle host), patch on top of 3.19.0. Extracting the functions involved in the decimal conversion I get new1.txt: 2.35% top [kernel.kallsyms] [k] num_to_str new2.txt: 2.70% top [kernel.kallsyms] [k] num_to_str old1.txt: 2.25% top [kernel.kallsyms] [k] num_to_str old2.txt: 2.18% top [kernel.kallsyms] [k] num_to_str new1.txt: 0.63% top [kernel.kallsyms] [k] put_dec new2.txt: 0.71% top [kernel.kallsyms] [k] put_dec old1.txt: 0.67% top [kernel.kallsyms] [k] put_dec old2.txt: 0.59% top [kernel.kallsyms] [k] put_dec new1.txt: 0.53% top [kernel.kallsyms] [k] put_dec_full8 new2.txt: 0.55% top [kernel.kallsyms] [k] put_dec_full8 old1.txt: 1.09% top [kernel.kallsyms] [k] put_dec_full9 old2.txt: 1.15% top [kernel.kallsyms] [k] put_dec_full9 new1.txt: 1.12% top [kernel.kallsyms] [k] put_dec_trunc8 new2.txt: 1.22% top [kernel.kallsyms] [k] put_dec_trunc8 old1.txt: 1.64% top [kernel.kallsyms] [k] put_dec_trunc8 old2.txt: 1.65% top [kernel.kallsyms] [k] put_dec_trunc8 I can't explain why num_to_str apparently becomes slightly slower (the patch essentially didn't touch it), but the put_dec_ helpers in any case make up for that. If someone has a suggestion for a better way of measuring this I'm all ears. Thanks, Rasmus [1] in terms of #cycles [2] numbers for 2000 and 5000 processes are quite similar.