From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754932AbbE1Uka (ORCPT ); Thu, 28 May 2015 16:40:30 -0400 Received: from terminus.zytor.com ([198.137.202.10]:52786 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754711AbbE1UkX (ORCPT ); Thu, 28 May 2015 16:40:23 -0400 Message-ID: <55677CEF.6040305@zytor.com> Date: Thu, 28 May 2015 13:39:11 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Borislav Petkov CC: Prarit Bhargava , Joe Perches , luto@amacapital.net, peterz@infradead.org, dvlasenk@redhat.com, torvalds@linux-foundation.org, imammedo@redhat.com, brgerst@gmail.com, mingo@kernel.org, dave.hansen@linux.intel.com, fenghua.yu@intel.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, bp@suse.de, linux-tip-commits@vger.kernel.org Subject: Re: [tip:x86/cpu] x86/cpu: Strip any /proc/ cpuinfo model name field whitespace References: <1432050210-32036-1-git-send-email-prarit@redhat.com> <1432628901-18044-15-git-send-email-bp@alien8.de> <1432746454.2846.154.camel@perches.com> <20150527190626.GC19407@pd.tnic> <1432754207.2846.162.camel@perches.com> <5566FB97.5020904@redhat.com> <20150528113229.GA31800@pd.tnic> <20150528125819.GB31800@pd.tnic> <2A88ADE0-90EF-4A94-BF4D-463E478B2FDA@zytor.com> <20150528183321.GD31800@pd.tnic> In-Reply-To: <20150528183321.GD31800@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/28/2015 11:33 AM, Borislav Petkov wrote: > On Thu, May 28, 2015 at 09:57:15AM -0700, H. Peter Anvin wrote: >> Why?! >> >> We are taking about 48 bytes run once per cpu. It isn't worth it to >> optimize, in fact the extra code size hurts more. > > I wanted to save us the redundant copying of the exact same bytes. > Because when there's no preceding whitespace, p and q point at the same > thing so we end up doing *p = *p. > > OTOH, without the optimization, the code is even simpler. > > I can remove it if you wanna - I don't care all that much. > Yes, please. Actually, with a test inside the loop the way you have it, the resulting code will almost certainly be slower -- a redundant write to an already dirty cache line is way cheaper than a branch. -hpa