Xen devel - Jul 2008 - cpufreq info propagation

Now that I finally got around to update our sources, I had a closer look at
those changes, and apart from stylistic issues on the Linux side (part of
which I may have asked for, but the result was somewhat overdone so
the code is hardly legible now - I''ve got a patch queued to streamline
this
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.

Besides that I continue to wonder what significance the support for
Dom0-controlled cpufreq handling has now that Xen has the ability to
handle that. I ask this not the least because so far we disabled the
CPU_FREQ config option in our kernels, partly because of the unknown
status of all of the different low level drivers (powernow-k8 supposedly
works, acpi-cpufreq apparently might work, too, but most others I''m
pretty unclear about), but also because of the massive (and afaict
not upstream) changes to powernow-k8 (which we simply don''t apply
at present) as well as due to the extra constraints that are required/
enforced when Dom0 is in charge.

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
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.

As a minor observation, I also find the naming vs. meaning of the
FREQCTL_none enumerator misleading - shouldn''t this rather be
FREQCTL_xen?

Jan


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

>From: Jan Beulich
>Sent: 2008年7月23日 16:21
>
>Now that I finally got around to update our sources, I had a 
>closer look at
>those changes, and apart from stylistic issues on the Linux 
>side (part of
>which I may have asked for, but the result was somewhat overdone so
>the code is hardly legible now - I''ve got a patch queued to 
>streamline this
thank you.
>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?
>
>Besides that I continue to wonder what significance the support for
>Dom0-controlled cpufreq handling has now that Xen has the ability to
>handle that. I ask this not the least because so far we disabled the
>CPU_FREQ config option in our kernels, partly because of the unknown
>status of all of the different low level drivers (powernow-k8 
>supposedly
>works, acpi-cpufreq apparently might work, too, but most others I''m
>pretty unclear about), but also because of the massive (and afaict
>not upstream) changes to powernow-k8 (which we simply don''t apply
>at present) as well as due to the extra constraints that are required/
>enforced when Dom0 is in charge.
If no existing usage already with dom0-controlled cpufreq, I agree 
that support is not necessary. The aim in original design when 
adding Xen cpufreq control, is to not break compatibility if any 
usage or release sticks to that style already.
>
>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.
>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.
The interface you cited is not the one to report freq statistics to
user, which instead is the point to parse ACPI Px information which
will be further hypercalled to Xen later when extcnl controller is
notified. Statistics information is conveyed by sysctl interface by
far.
>
>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.

Thanks,
Kevin

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

>>> "Tian, Kevin" <kevin.tian@intel.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Jan Beulich
>Sent: 2008年7月23日 18:13
>>
>>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.
Agree then. We''ll send out a fix.
>
>>>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.
My answer was to xen controlled cpufreq. As I said below, xen cmd
line option and dom0 CONFIG_CPU_FREQ are two conditions to 
enable xen controlled cpufreq. When FREQCTL_xen is set, cpufreq
driver/governor within xen is enabled, which however doesn''t start
working until someone (dom0) notifies xen about processor freq info.
When dom0 CPU_FREQ is enabled, extcnl logic then attempts to
parse ACPI px info and then notify Xen by hypercall. After that, Xen
cpufreq begins working.

I think we may enable CPU_FREQ in dom0''s config by default, to 
eliminate such disconnected logic.
>
>>>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).
You''re right. This is a bug to gracefully handle such corner 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.
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.

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.

Note that similar story will be repeated in the future, if any feature
is tightly coupled with ACPI, e.g. RAS.
>
>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.
Yes, we need handle it better. A patch will be made before 3.3.

As a summary, (if I have answered your concerns), both xen-controlled
and dom0-controlled options are working in normal case, with some
corner case conflicting not handled cleanly. They both require 
CPU_FREQ being enabled to work.
>
>>>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).
>
Sorry that I didn''t read code carefully, as I thought there should be
a FREQCTL_xen already. It''s a silly one, and should be fixed.

Thanks
Kevin

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