WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel][PATCH] Change cpufreq_driver->get so that it can get oth

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel][PATCH] Change cpufreq_driver->get so that it can get other cpu's real physical freq
From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Date: Thu, 11 Dec 2008 18:27:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Thu, 11 Dec 2008 02:28:22 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C56689EB.20150%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <706158FABBBA044BAD4FE898A02E4BC21C53A738@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C56689EB.20150%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclbOgEoxNcqeyIPRwCqcDCotFfXvAAAwl3wAAFJveAAC5bB+QACnjJg
Thread-topic: [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.

Keir,

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

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