[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] c/s 18470


  • To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
  • From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
  • Date: Thu, 18 Sep 2008 18:19:51 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 18 Sep 2008 03:20:17 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AckZZ8mR2fS1JFRgRoyNCbIXw6L+0wADxqEg
  • Thread-topic: [Xen-devel] c/s 18470

Jan Beulich wrote:
>>>> "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> 18.09.08 09:39 >>>
>> Jan Beulich wrote:
>>> Likewise the calls to cpufreq_{add,del}_cpu() from the CPU
>>> hot(un)plug paths seem to consider the Intel case only (as the
>>> functions themselves are Intel specific).
>> 
>> [Jinsong]:
>>  Not quite sure about your question. I just check the code:
>>  1. cpufreq_add/del_cpu() is arch-independent, since all
>> arch-dependent part has been handled by cpufreq_driver->init/exit().
>>  2. cpu online/offline path is also arch-independent.
>>  Would you please tell me more clear where is intel specific?
> 
> In that platform_hypercall.c calls cpufreq_add_cpu() only for Intel
> CPUs, but the hotplug code calls it and cpufreq_del_cpu() always.
> This ought to be consistent I believe.

Thanks for pointing out this point!
Yes, currently Intel and AMD differ at cpufreq init point, and they are
not consistent.
However, after we complete cpufreq rebase and IPF support, AMD powernow
can also stop using their init method, and using our common code
cpufreq_add_cpu() and cpufreq_del_cpu() since the code is
arch-independent. At that time, both Intel and AMD cpufreq init and
online/offline logic are consistent.

Thanks,
Jinsong

> 
> Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.