From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751358AbcBBABm (ORCPT ); Mon, 1 Feb 2016 19:01:42 -0500 Received: from mga14.intel.com ([192.55.52.115]:64236 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbcBBABl (ORCPT ); Mon, 1 Feb 2016 19:01:41 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,382,1449561600"; d="scan'208";a="894187439" Date: Mon, 1 Feb 2016 16:00:33 -0800 From: Andi Kleen To: Rasmus Villemoes Cc: Andi Kleen , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, davidlohr.bueso@hp.com, rafael.j.wysocki@intel.com, lenb@kernel.org Subject: Re: [PATCH] Optimize int_sqrt for small values for faster idle Message-ID: <20160202000033.GB15302@tassilo.jf.intel.com> References: <1454017365-8509-1-git-send-email-andi@firstfloor.org> <87y4b4azsy.fsf@rasmusvillemoes.dk> <20160201213622.GA15302@tassilo.jf.intel.com> <87powgav0h.fsf@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87powgav0h.fsf@rasmusvillemoes.dk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 02, 2016 at 12:08:46AM +0100, Rasmus Villemoes wrote: > On Mon, Feb 01 2016, Andi Kleen wrote: > > > On Mon, Feb 01, 2016 at 10:25:17PM +0100, Rasmus Villemoes wrote: > >> On Thu, Jan 28 2016, Andi Kleen wrote: > >> > >> > From: Andi Kleen > >> > > >> > The menu cpuidle governor does at least two int_sqrt() each time > >> > we go into idle in get_typical_interval to compute stddev > >> > > >> > int_sqrts take 100-120 cycles each. Short idle latency is important > >> > for many workloads. > >> > > >> > >> If you want to optimize get_typical_interval(), why not just take the > >> square root out of the equation (literally)? > >> > >> Something like > > > > Looks good. Yes that's a better fix. > > > > Thanks. (Is there a good way to tell gcc that avg*avg is actually a > 32x32->64 multiplication?) I don't think there is, but you could define a custom macro with a fallback on pure 64x64->64. -Andi