linux-kernel - RE: Dependent CPU core speed reporting not updated with CPUFREQ_SHARED_TYPE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <653FFBB4508B9042B5D43DC9E18836F5F5B11F@scsmsx415.amr.corp.intel.com>
Date:	Fri, 1 Jun 2007 18:59:25 -0700
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	"Darrick J. Wong" <djwong@...ibm.com>
Cc:	<linux-kernel@...r.kernel.org>, "Dave Jones" <davej@...hat.com>
Subject: RE: Dependent CPU core speed reporting not updated with CPUFREQ_SHARED_TYPE_HW?

>-----Original Message-----
>From: Darrick J. Wong [mailto:djwong@...ibm.com] 
>Sent: Friday, June 01, 2007 11:44 AM
>To: Pallipadi, Venkatesh
>Cc: linux-kernel@...r.kernel.org
>Subject: Re: Dependent CPU core speed reporting not updated 
>with CPUFREQ_SHARED_TYPE_HW?
>
>On Thu, Mar 29, 2007 at 06:06:22PM -0700, Pallipadi, Venkatesh wrote:
>> thought of
>> making affected CPUs show the dependency in case of hw coord, but
>> retaining the percpu
>> control. But, it seemed complicated change for something that is
>> cosmetic.
>
>Actually, it's not so cosmetic any more.  Our newest servers have a
>power meter that measures power consumption, and I'm writing a program
>to measure the power cost of various cpufreq transitions in order to
>enforce a power cap.  Due to the under-reporting in affected_cpus, the
>app thinks that (taking your example above) CPUs 0 and 2 can be
>controlled independently.  Thus, a p-state transition of (x, x) ->
>(x, x-1) yields no energy saving at all, while (x, x-1) -> (x-1, x-1)
>does.  My program considers the effects of a single CPU's transition
>independently of which CPU it is and without considering what
>frequencies the other CPUs are operating at, which means that it will
>conclude that the cost of increasing speed (or the reward for 
>decreasing
>it) is half of what it is ... sort of.  It's mildly broken as a result,
>though amusingly enough it still seems to work ok.  I suspect that it
>might flail around trying to hit a cap a bit more than it would if
>affected_cpus were more accurate.

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

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.

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.

Comments? Thoughts?

Thanks,
Venki  
-
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/