From mboxrd@z Thu Jan 1 00:00:00 1970 From: Len Brown Subject: Re: [PATCH] acpi-cpufreq: remove unreliable get-frequency functions Date: Tue, 07 Jun 2011 00:07:46 -0400 (EDT) Message-ID: References: <20110606071209.GA20080@isilmar-3.linta.de> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-reply-to: <20110606071209.GA20080@isilmar-3.linta.de> Sender: cpufreq-owner@vger.kernel.org To: Dominik Brodowski Cc: linux-acpi@vger.kernel.org, cpufreq@vger.kernel.org, Arjan van de Ven List-Id: linux-acpi@vger.kernel.org > Why can't it be fixed in silicon for future chips? > May there be workarounds possible in the CPU microcode? Not going to happen. > The APERF MSR is not a real > alternative to a real "get current frequency" function (which I have > wished to be added to the ACPI spec for how long? must be close to 10 > years...): APERF only allows you to get an average frequency, and not the > current frequency at the time of the call. Instantaneous frequency can change many times per second. What benefit is there to reporting someting that changes that fast to readers of sysfs? > For silicon which can't be fixed any more, using APERF instead may be a > valid -- but costly[*] -- solution. For other CPUs, I'd favour keeping > the current code -- even if Intel CPUs aren't capable to reliably tell > which frequency they're running at. APERF is expensive how? ondemand, which does care about average frequency, has been using APERF for years. > Finally: > > > + policy->cur = data->freq_table[data->acpi_data->state].frequency; > > How do you know what state / frequency the CPU is running here? really the correct fix is for the upper level of cpufreq to simply no export this value at all, or to export the value that was last written. A driver should be free to decline to supply any current value. thanks, Len Brown, Intel Open Source Technology Center