[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070602064325.GB7445@redhat.com>
Date: Sat, 2 Jun 2007 02:43:25 -0400
From: Dave Jones <davej@...hat.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
Cc: "Darrick J. Wong" <djwong@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists