From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753798Ab1CLLlM (ORCPT ); Sat, 12 Mar 2011 06:41:12 -0500 Received: from mail-fx0-f46.google.com ([209.85.161.46]:48816 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753302Ab1CLLlH (ORCPT ); Sat, 12 Mar 2011 06:41:07 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=V6/4ftIibh+ZVJvscmEGmxdiExvehvhVvk5aF/PB2UKox86XBLc6pjBAE5FKRSWitg YvMQaStIWtPmCDFJjuMsL9vJ2XjHbTIWowidVu5o7JUwtim5L5rK+J+I6GWNHZcPND1H KjCIPjckN9TQJKzxYoqU75Ozf4NX7ab/MvFd4= Date: Sat, 12 Mar 2011 12:41:01 +0100 From: Tejun Heo To: Christoph Lameter Cc: akpm@linux-foundation.org, Pekka Enberg , linux-kernel@vger.kernel.org, Eric Dumazet , Mathieu Desnoyers , x86@kernel.org Subject: Re: [x86 this_cpu_has V1 2/4] x86: Avoid passing struct cpuinfo pointer to mce_available Message-ID: <20110312114101.GB2005@htj.dyndns.org> References: <20110311162310.124405247@linux.com> <20110311162334.162046931@linux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110311162334.162046931@linux.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 11, 2011 at 10:23:12AM -0600, Christoph Lameter wrote: > If we do not pass the pointer to cpuinfio to mce available then its possible > to use this_cpu_has. > > There are two use cases of mce_available: One with the current processor > and one with the boot cpu. Define a function for both cases. However, there > is only one case in which boot_mce_available is used. If we somehow can > get rid of that then the patch could be simplified. > > Signed-off-by: Christoph Lameter Christoph, I'm not sure about this one. None of the conversions is in hot path, which would be okay if the resulting code was simpler but, well, it isn't necessarily worse but not distinctively better either, so I fail to see the merits of this conversion. I'll resend the other three towards x86 tree. Thank you. -- tejun