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

RE: [Xen-devel][PATCH] Change cpufreq_driver->get so that it can get other cpu's real physical freq

Keir Fraser wrote:
> On 11/12/2008 04:15, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>>> Above is a bad change where you kicks multiple cpus to update
>>> same variable without any coordination. Also why can short path only
>>> be used with strict condition that current cpu must be first bit in
>>> mask? As long as current cpu is on mask, you can always read
>>> directly.
>> No need any coordination here, please notice under whatever
>> situation, there is only 1 bit set at cpumask here (we can only read
>> the value of 1 cpu 1 time).
> Then please ASSERT(cpus_weight(cmd->mask) == 1) to make this
> constraint clear.
>> The first bit of cpumask here is not to set strict condition for
>> short path. In fact, becuase of only 1 bit set at cpumask, the
>> first_cpu() is only used to get its cpuid. If cpuid is the running
>> cpu, go short path, otherwise go longer path.
> The clearer (and faster) idiom is cpu_isset(smp_processor_id(),
> cmd->mask). 
> Please can you make these changes, test, and re-send.
>  Thanks,
>  Keir
>> In fact, get_cur_val() was called by 2 paths (driver path and
>> check_freq path), we design here is used to provide a unified
>> interface to satisfied the requirement of both paths.


Thanks for comments, the patch has been updated and tested, will send out later.

Xen-devel mailing list



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