>-----Original Message----- >From: Darrick J. Wong [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 29, 2007 5:43 PM >To: Pallipadi, Venkatesh >Cc: linux-kernel@vger.kernel.org >Subject: Dependent CPU core speed reporting not updated with >CPUFREQ_SHARED_TYPE_HW? > >Hi Venki, > >I have a dual-Woodcrest machine here with _PSD tables that specify that >cpufreq coordination between cores is done in hardware with >DOMAIN_COORD_TYPE_HW_ALL. On this particular machine, CPU 0 and CPU 2 >are on the same package, and it looks like they have to be at the same >frequency. > >However, it seems that acpi_cpufreq_cpu_init() only sets >policy->cpus to >the shared cpu mask if software coordination is required. While this >does have the effect of letting the hardware do its coordination job as >advertised, it also means that a frequency change to CPU0 doesn't get >echoed to CPU2 as it should be, and affected_cpus is inaccurate. > >This seems like a bug to me. I can whip up a patch to set the policy >cpu mask in all cases and neuter all but one of the MSR/PCT >writes if HW >coordination is desired so that HW coordination is preserved and sysfs >is accurate, but I'm curious to know if I've gotten it right. >
Darrick, Above observation is correct. Affected_cpus and policy->cpus has multiple entry only when software coordination is desired. If hardware is doing the coordination, then setting policy->cpus makes another level of sw coordination on top of hardware coordination. The main reason is why I chose the current way is, from kernel perspective doing it at each logical CPU is much better than doing software coordination and making one CPU look at utilization of different CPUs and take decisions on their behalf. Especially with tickless kind of situations, Example: say CPU 0 and CPU 2 are sharing frequency with hw coordination and we make CPU 2 MSR lowest at all times and run the ondemand policy on CPU 0 to control both CPUs. Now CPU 0 is idle and CPU 2 gets some load. Ideally it will be better for CPU 2 to recognise and handle it, rather than wait for CPU 1 to come out of idle and handle this at a later point in time. Having the policy per CPU and dealing with hw coordination locally also simplifies CPU hotplug handling. I agree that affected_cpus is lying in case of hardware coordination. I 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. Note that this issue is the problem with what we display as current freq. However, ondemand knows the current freq of each CPU correctly even in this case, as it uses measured_freq interface that is supported on all recent processors to make frequency decisions. Thanks, Venki - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/