From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753915AbbDOJg7 (ORCPT ); Wed, 15 Apr 2015 05:36:59 -0400 Received: from cantor2.suse.de ([195.135.220.15]:34505 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751276AbbDOJgw (ORCPT ); Wed, 15 Apr 2015 05:36:52 -0400 Message-ID: <552E3132.6030804@suse.cz> Date: Wed, 15 Apr 2015 11:36:50 +0200 From: Michal Marek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Guenter Roeck , Randy Dunlap CC: Alexey Dobriyan , akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] tags: much faster, parallel "make tags" References: <20150414172047.GA5641@p183.telecom.by> <552D72F5.3060404@infradead.org> <20150414202450.GA20232@roeck-us.net> In-Reply-To: <20150414202450.GA20232@roeck-us.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015-04-14 22:24, Guenter Roeck wrote: > On Tue, Apr 14, 2015 at 01:05:09PM -0700, Randy Dunlap wrote: >> On 04/14/15 10:20, Alexey Dobriyan wrote: >>> ctags is single-threaded program. Split list of files to be tagged into >>> equal parts, 1 part for each CPU and then merge the results. >>> >>> Speedup on one 2-way box I have is ~143 s => ~99 s (-31%). >>> On another 4-way box: ~120 s => ~65 s (-46%!). >>> >>> Resulting "tags" files aren't byte-for-byte identical because ctags >>> program numbers anon struct and enum declarations with "__anonNNN" >>> symbols. If those lines are removed, "tags" file becomes byte-for-byte >>> identical with those generated with current code. >>> >>> Signed-off-by: Alexey Dobriyan >>> --- >>> >>> scripts/tags.sh | 34 ++++++++++++++++++++++++++++++++-- >>> 1 file changed, 32 insertions(+), 2 deletions(-) >>> >>> --- a/scripts/tags.sh >>> +++ b/scripts/tags.sh >>> @@ -152,7 +152,24 @@ dogtags() >>> >>> exuberant() >>> { >>> - all_target_sources | xargs $1 -a \ >>> + NR_CPUS=1 >>> + if [ -e /proc/cpuinfo ]; then >>> + NR_CPUS=$(grep -e '^processor : ' /proc/cpuinfo | wc -l) >> >> That grep is rather arch-specific. If an arch does not have that string >> (with an embedded tab), won't NR_CPUS be zero? so at least, set it back to 1? >> >> or (if 'getconf' is installed): >> NR_CPUS = `getconf _NPROCESSORS_ONLN` >> > What is wrong with nproc ? It's too new. 'getconf _NPROCESSORS_ONLN' has been available since 1996 according to glibc.git. Michal