tags 449307 + patch
thanks
On Sun, Dec 09, 2007 at 06:07:31PM +1000, Kel Modderman wrote:
...
> > This would be cpufreq specific knowledge that can fit into cpufrequtils,
> > other than that I can't really see the point of implementing this
> > generic cpu-index thing in cpufreq-info when this inf
tags 449307 - patch
thanks
On Sunday 09 December 2007 16:42:42 Mattia Dongili wrote:
> On Wed, Dec 05, 2007 at 10:09:28AM +1000, Kel Modderman wrote:
> > On Wednesday 05 December 2007 09:54:30 Mattia Dongili wrote:
>
> ...
>
> > > and guess how cpufreq-info reads the number of cores? :)
> >
> > Fr
On Wed, Dec 05, 2007 at 10:09:28AM +1000, Kel Modderman wrote:
> On Wednesday 05 December 2007 09:54:30 Mattia Dongili wrote:
...
> > and guess how cpufreq-info reads the number of cores? :)
>
> From /proc/stat.
haha, sorry... funny thing is that I wrote that code... I should have
known about it.
On Wednesday 05 December 2007 09:54:30 Mattia Dongili wrote:
> On Tue, Dec 04, 2007 at 08:38:57PM +1000, Kel Modderman wrote:
> > tags 449307 patch
> > thanks
>
> Hi Kel
>
> > I couldn't reproduce the reporters problems, but I do kinda think it
> > makes since to use cpufreq-info to count cpu cores
On Tue, Dec 04, 2007 at 08:38:57PM +1000, Kel Modderman wrote:
> tags 449307 patch
> thanks
Hi Kel
> I couldn't reproduce the reporters problems, but I do kinda think it makes
> since to use cpufreq-info to count cpu cores rather than /proc/*. At least
> the maintainer is in charge of the outpu
tags 449307 patch
thanks
I couldn't reproduce the reporters problems, but I do kinda think it makes
since to use cpufreq-info to count cpu cores rather than /proc/*. At least
the maintainer is in charge of the output format in this case, and not at the
hands of the variable kernel of the day...
6 matches
Mail list logo