Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754644AbaBDOxp (ORCPT ); Tue, 4 Feb 2014 09:53:45 -0500 Received: from mga14.intel.com ([143.182.124.37]:31113 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752631AbaBDOxn (ORCPT ); Tue, 4 Feb 2014 09:53:43 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,780,1384329600"; d="scan'208";a="338703564" Message-ID: <52F0FEF5.1010908@linux.intel.com> Date: Tue, 04 Feb 2014 06:53:41 -0800 From: Arjan van de Ven User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ingo Molnar , Peter Zijlstra CC: Morten Rasmussen , Nicolas Pitre , Daniel Lezcano , Preeti U Murthy , Len Brown , Preeti Murthy , "mingo@redhat.com" , Thomas Gleixner , "Rafael J. Wysocki" , LKML , "linux-pm@vger.kernel.org" , Lists linaro-kernel Subject: Re: [RFC PATCH 3/3] idle: store the idle state index in the struct rq References: <20140131090230.GM5002@laptop.programming.kicks-ass.net> <52EB6F65.8050008@linux.vnet.ibm.com> <52EBBC23.8020603@linux.intel.com> <52EBC33A.6080101@linaro.org> <52EBC645.2040607@linux.intel.com> <20140203125441.GD19029@e103034-lin> <52EFA9D3.1030601@linux.intel.com> <20140203145605.GL8874@twins.programming.kicks-ass.net> <20140204091405.GB19156@gmail.com> In-Reply-To: <20140204091405.GB19156@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Yeah, so we could put the parameters back by measuring it in > user-space via a nice utility in tools/, and by matching it to > relevant hardware signatures (CPU type and cache sizes), plus doing > some defaults for when we don't have any signature... possibly based > on a fuzzy search to find the 'closest' system in the table of > constants. > > That would stabilize the boot-to-boot figures while still keeping most > of the system specific-ness, in a maintainable fashion. > > The downside is that we'd have to continuously maintain a table of all > this info, with new entries added when new CPUs are introduced on the > market. That's an upside too, btw. for bigger systems this will also depend on the chipset and even motherboard since inter-CPU communication may go via a 3rd party chip and the speed of that will depend on how far they are apart... like a 32 socket machine it'll be very different from a 2 socket machine, and from the 32 socket machine from another vendor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/