lkml.org 
[lkml]   [2007]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Dependent CPU core speed reporting not updated with CPUFREQ_SHARED_TYPE_HW?
On Fri, Jun 01, 2007 at 06:59:25PM -0700, Venki Pallipadi wrote:

> Hmmm. How about having a new cpufreq_sysfs entry to say
> these CPUs are frequency dependent in hardware.

Wait, wasn't this the entire purpose of affected_cpus in the first
place? So we could see which CPUs would be affected by a frequency
change? What went wrong here?

> affected_cpus today has a single cpufreq directory for all affected_cpus
> and we coordinate all CPUs in software. To change freq, we will have to
> move among all affected_cpus and write an MSR.

This I think is where the problem started. That these remained
independant. Changing one should also affect the others that it
'affects'. Is that not the case?

> Hardware coordination basically tells us that kernel can control
> frequency
> percpu, but underneath hardware will pick highest requested freq among a
> group of CPUs. Instaed of handling this case as the existing software
> coordination case above, we can add a new entry in cpufreq /sysfs
> denoting
> hardware coordinated CPU group.
>
> Though it will be confusing with too many interfaces, I feel this is the
> right way to go about here.

If 'affected_cpus' doesn't do the right thing, I'd vote for making it
do so over adding more interfaces.

Dave

--
http://www.codemonkey.org.uk
-
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/

\
 
 \ /
  Last update: 2007-06-02 08:47    [W:1.113 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site