RE: FW: [Xen-devel] cpufreq info propagation

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
>Sent: 2008年7月24日 22:18
>
>>Processor freq info is contained in ACPI Px methods in AML style,
>>and thus there's no way for Xen to retrieve them without dom0's help.
>>However existing ACPI parse logic is only compiled when CPU_FREQ 
>>is configured. It'd be mess to copy those code out of CPU_FREQ.
>
>I understand that - an alternative idea was to enable CONFIG_CPU_FREQ
>by a (conditional) #define in the relevant core ACPI files. But that
>should probably be considered only if getting things to work 
>by tweaking
>the core cpufreq code turns out to be no less intrusive.

Yes, we thought that alternative in the start, but then give up since
it makes code a bit messed. Actually this is similar dependency
as on ACPI PROCESSOR module, as you changed it back to 'm'
yesterday.

>
>>Also enable CPU_FREQ in dom0 doesn't mean the control goes to
>>dom0. Dom0 only tempts to control when cpufreq driver is loaded, 
>>and by far the driver is hacked from loading when extcnl is 
>requesting.
>>This is a bit hacky, and the cleaner way should move such check
>>to generic cpufreq layer since there're so many drivers.
>
>Indeed, if that was done e.g. by making cpufreq_register_driver()
>fail in this case, I would feel much safer allowing the CPU_FREQ
>options again. But that would imply that all the drivers behave

Yes, that's the option we tempt to do.

>properly when that registration fails, and while powernow-k8
>appears to do so, acpi-cpufreq doesn't seem to - it would (in .26)
>at least leak per-CPU data allocated in acpi_cpufreq_early_init().

But there's no way to make it elegant, as cpufreq drivers themselves
are initialized independently except the registration hooked to core
cpufreq layer. If we really want to make absolutely clean, case by
case check and hack has to be done per each cpufreq driver. But
I guess that's not worthy as even some data leaked which won't be
accumulative.

>
>What I'm still unclear about is the role of the kernel governors when
>Xen controls cpufreq.
>

As you already perceived, the purpose is just to use some ACPI
Px parse logic. But to avoid intrusive change to existing linux code,
we choose a coarse-level option to enable whole CPU_FREQ. 
When kernel image size is enlarged a bit, no runtime overhead is
added as kernel governors are not activated at all when driver is
not registered, IIRC. :-)

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel