|
xen-devel
RE: [Xen-devel] cpufreq info propagation
>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 23.07.08 10:57 >>>
>>a little) I find it rather odd (fragile) that the
>>who-is-in-charge information
>>gets propagated via a command line option rather than through the
>>startup info. I think this should be adjusted before 3.3 gets frozen.
>
>startup info is viable. But how fragile is the cmdline option?
If the user passes an option like this manually, depending on the
particular kernel version's logic of parsing options, this may result in
conflicts and hence misbehavior. Using the startup info avoids such
collisions. Likewise, this method doesn't scale, since the command line
cannot grow arbitrarily large.
>>In any case there is an open question for me as to how current status
>>is being reported to the user (at least in Dom0) on the current CPU
>>frequency in use when CPU_FREQ is configured off (and I have to
>
>If CPU_FREQ is off, error is returned when user tries to query
>cpufreq information from Xen.
You mean when (in Xen) control is set to FREQCTL_dom0_kernel. But
my question was how this works when CPU_FREQ is configured off
in the kernel, but Xen is (told to [? - see below]) control(ling) cpufreq.
>>admit that while I didn't try it, I suspect it doesn't even work when
>>CPU_FREQ is on - this is because the apparently only reporting
>>function, processor_extcntl_get_performance(), is being called
>>exclusively in the context of acpi_processor_start()). With that I
>>wonder how I would be able to determine whether the code works
>>at all.
>
>Not sure about your concern. Currently xen-controlled cpufreq isn't
>enabled by default. User needs pass xen cmdline and also enable
>dom0 CPU_FREQ. Once that's done, everything should work.
At least as enabling in Xen is concerned, I can't see this is the case: the
respective initializer functions are being called out of the
XENPF_set_processor_pminfo handler unconditonally. I.e. I'm missing
where this logic would be suppressed (kind of a
ret = -ENOSYS;
if ( cpufreq_controller != FREQCTL_xen )
break;
missing at the top of the XEN_PM_PX sub-case).
Further, tying the functionality to CPU_FREQ being enabled in Dom0
seems odd to me, too: Who is controlling what then? I thought it's solely
in the hypervisor's hands, and in that case involving the whole cpufreq
machinery (including the governors) in the kernel appears pointless.
Additionally, there's nothing being done to prevent the collision with
other low-level drivers. acpi-cpufreq and powernow-k8 have got an
early-out clause into their startup inserted, but all other drivers have
been left alone. And with Xen being the preferred cpufreq controller,
in my opinion there ought to be an option to enable that in the kernel
which would automatically suppress all low-level drivers.
>>As a minor observation, I also find the naming vs. meaning of the
>>FREQCTL_none enumerator misleading - shouldn't this rather be
>>FREQCTL_xen?
>
>If user wants to disable cpufreq at all, a FREQCTL_none option is
>required.
Right, but I can't see where it's used (i.e. where a distinction is made
between no and Xen-based cpufreq handling).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home