All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] use per-cpu variables in cpufreq
@ 2011-05-27 11:11 Juergen Gross
  2011-05-27 13:11 ` Keir Fraser
  2011-06-10 19:00 ` Langsdorf, Mark
  0 siblings, 2 replies; 13+ messages in thread
From: Juergen Gross @ 2011-05-27 11:11 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

The cpufreq driver used some local arrays indexed by cpu number. This patch
replaces those arrays by per-cpu variables. The AMD and INTEL specific parts
used different per-cpu data structures with nearly identical semantics.
Fold the two structures into one by adding a generic architecture data item.

Signed-off-by: juergen.gross@ts.fujitsu.com


8 files changed, 58 insertions(+), 66 deletions(-)
xen/arch/x86/acpi/cpufreq/cpufreq.c       |   36 ++++++++++++------------
xen/arch/x86/acpi/cpufreq/powernow.c      |   43 +++++++++++------------------
xen/drivers/acpi/pmstat.c                 |    6 ++--
xen/drivers/cpufreq/cpufreq.c             |   24 ++++++++--------
xen/drivers/cpufreq/cpufreq_ondemand.c    |    2 -
xen/drivers/cpufreq/utility.c             |    8 ++---
xen/include/acpi/cpufreq/cpufreq.h        |    3 +-
xen/include/acpi/cpufreq/processor_perf.h |    2 -



[-- Attachment #2: xen-work.patch --]
[-- Type: text/x-patch, Size: 18325 bytes --]

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1306494655 -7200
# Node ID eb601128d8930496007695233022b904fc62e039
# Parent  88fe9f780b3d0cf0fcd5aa9b87d4ec7ad404e985
use per-cpu variables in cpufreq

The cpufreq driver used some local arrays indexed by cpu number. This patch
replaces those arrays by per-cpu variables. The AMD and INTEL specific parts
used different per-cpu data structures with nearly identical semantics.
Fold the two structures into one by adding a generic architecture data item.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 88fe9f780b3d -r eb601128d893 xen/arch/x86/acpi/cpufreq/cpufreq.c
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c	Thu May 26 17:16:47 2011 +0100
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c	Fri May 27 13:10:55 2011 +0200
@@ -54,7 +54,7 @@ enum {
 #define INTEL_MSR_RANGE         (0xffffull)
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY       (0x1)
 
-static struct acpi_cpufreq_data *drv_data[NR_CPUS];
+DEFINE_PER_CPU(struct acpi_cpufreq_data *, cpufreq_data);
 
 static struct cpufreq_driver acpi_cpufreq_driver;
 
@@ -103,7 +103,7 @@ static unsigned extract_msr(u32 msr, str
 
 static unsigned extract_freq(u32 val, struct acpi_cpufreq_data *data)
 {
-    switch (data->cpu_feature) {
+    switch (data->arch_cpu_flags) {
     case SYSTEM_INTEL_MSR_CAPABLE:
         return extract_msr(val, data);
     case SYSTEM_IO_CAPABLE:
@@ -213,17 +213,17 @@ static u32 get_cur_val(const cpumask_t *
         return 0;
 
     policy = per_cpu(cpufreq_cpu_policy, cpu);
-    if (!policy || !drv_data[policy->cpu])
+    if (!policy || !per_cpu(cpufreq_data, policy->cpu))
         return 0;    
 
-    switch (drv_data[policy->cpu]->cpu_feature) {
+    switch (per_cpu(cpufreq_data, policy->cpu)->arch_cpu_flags) {
     case SYSTEM_INTEL_MSR_CAPABLE:
         cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
         cmd.addr.msr.reg = MSR_IA32_PERF_STATUS;
         break;
     case SYSTEM_IO_CAPABLE:
         cmd.type = SYSTEM_IO_CAPABLE;
-        perf = drv_data[policy->cpu]->acpi_data;
+        perf = per_cpu(cpufreq_data, policy->cpu)->acpi_data;
         cmd.addr.io.port = perf->control_register.address;
         cmd.addr.io.bit_width = perf->control_register.bit_width;
         break;
@@ -372,7 +372,7 @@ static unsigned int get_cur_freq_on_cpu(
     if (!policy)
         return 0;
 
-    data = drv_data[policy->cpu];
+    data = per_cpu(cpufreq_data, policy->cpu);
     if (unlikely(data == NULL ||
         data->acpi_data == NULL || data->freq_table == NULL))
         return 0;
@@ -419,7 +419,7 @@ static int acpi_cpufreq_target(struct cp
 static int acpi_cpufreq_target(struct cpufreq_policy *policy,
                                unsigned int target_freq, unsigned int relation)
 {
-    struct acpi_cpufreq_data *data = drv_data[policy->cpu];
+    struct acpi_cpufreq_data *data = per_cpu(cpufreq_data, policy->cpu);
     struct processor_performance *perf;
     struct cpufreq_freqs freqs;
     cpumask_t online_policy_cpus;
@@ -456,7 +456,7 @@ static int acpi_cpufreq_target(struct cp
             return 0;
     }
 
-    switch (data->cpu_feature) {
+    switch (data->arch_cpu_flags) {
     case SYSTEM_INTEL_MSR_CAPABLE:
         cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
         cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
@@ -501,11 +501,11 @@ static int acpi_cpufreq_verify(struct cp
     struct acpi_cpufreq_data *data;
     struct processor_performance *perf;
 
-    if (!policy || !(data = drv_data[policy->cpu]) ||
-        !processor_pminfo[policy->cpu])
+    if (!policy || !(data = per_cpu(cpufreq_data, policy->cpu)) ||
+        !per_cpu(processor_pminfo, policy->cpu))
         return -EINVAL;
 
-    perf = &processor_pminfo[policy->cpu]->perf;
+    perf = &per_cpu(processor_pminfo, policy->cpu)->perf;
 
     cpufreq_verify_within_limits(policy, 0, 
         perf->states[perf->platform_limit].core_frequency * 1000);
@@ -557,9 +557,9 @@ acpi_cpufreq_cpu_init(struct cpufreq_pol
         return -ENOMEM;
     memset(data, 0, sizeof(struct acpi_cpufreq_data));
 
-    drv_data[cpu] = data;
+    per_cpu(cpufreq_data, cpu) = data;
 
-    data->acpi_data = &processor_pminfo[cpu]->perf;
+    data->acpi_data = &per_cpu(processor_pminfo, cpu)->perf;
 
     perf = data->acpi_data;
     policy->shared_type = perf->shared_type;
@@ -569,7 +569,7 @@ acpi_cpufreq_cpu_init(struct cpufreq_pol
         if (cpufreq_verbose)
             printk("xen_pminfo: @acpi_cpufreq_cpu_init,"
                    "SYSTEM IO addr space\n");
-        data->cpu_feature = SYSTEM_IO_CAPABLE;
+        data->arch_cpu_flags = SYSTEM_IO_CAPABLE;
         break;
     case ACPI_ADR_SPACE_FIXED_HARDWARE:
         if (cpufreq_verbose)
@@ -579,7 +579,7 @@ acpi_cpufreq_cpu_init(struct cpufreq_pol
             result = -ENODEV;
             goto err_unreg;
         }
-        data->cpu_feature = SYSTEM_INTEL_MSR_CAPABLE;
+        data->arch_cpu_flags = SYSTEM_INTEL_MSR_CAPABLE;
         break;
     default:
         result = -ENODEV;
@@ -652,17 +652,17 @@ err_freqfree:
     xfree(data->freq_table);
 err_unreg:
     xfree(data);
-    drv_data[cpu] = NULL;
+    per_cpu(cpufreq_data, cpu) = NULL;
 
     return result;
 }
 
 static int acpi_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 {
-    struct acpi_cpufreq_data *data = drv_data[policy->cpu];
+    struct acpi_cpufreq_data *data = per_cpu(cpufreq_data, policy->cpu);
 
     if (data) {
-        drv_data[policy->cpu] = NULL;
+        per_cpu(cpufreq_data, policy->cpu) = NULL;
         xfree(data->freq_table);
         xfree(data);
     }
diff -r 88fe9f780b3d -r eb601128d893 xen/arch/x86/acpi/cpufreq/powernow.c
--- a/xen/arch/x86/acpi/cpufreq/powernow.c	Thu May 26 17:16:47 2011 +0100
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c	Fri May 27 13:10:55 2011 +0200
@@ -53,15 +53,7 @@
 #define MSR_PSTATE_CUR_LIMIT    0xc0010061 /* pstate current limit MSR */
 #define MSR_HWCR_CPBDIS_MASK    0x02000000ULL
 
-struct powernow_cpufreq_data {
-    struct processor_performance *acpi_data;
-    struct cpufreq_frequency_table *freq_table;
-    unsigned int max_freq;
-    unsigned int resume;
-    unsigned int cpu_feature;
-};
-
-static struct powernow_cpufreq_data *drv_data[NR_CPUS];
+#define ARCH_CPU_FLAG_RESUME	1
 
 static struct cpufreq_driver powernow_cpufreq_driver;
 
@@ -92,7 +84,7 @@ static int powernow_cpufreq_target(struc
 static int powernow_cpufreq_target(struct cpufreq_policy *policy,
                                unsigned int target_freq, unsigned int relation)
 {
-    struct powernow_cpufreq_data *data = drv_data[policy->cpu];
+    struct acpi_cpufreq_data *data = per_cpu(cpufreq_data, policy->cpu);
     struct processor_performance *perf;
     struct cpufreq_freqs freqs;
     cpumask_t online_policy_cpus;
@@ -119,8 +111,8 @@ static int powernow_cpufreq_target(struc
 
     next_perf_state = data->freq_table[next_state].index;
     if (perf->state == next_perf_state) {
-        if (unlikely(data->resume)) 
-            data->resume = 0;
+        if (unlikely(data->arch_cpu_flags & ARCH_CPU_FLAG_RESUME)) 
+            data->arch_cpu_flags &= ~ARCH_CPU_FLAG_RESUME;
         else
             return 0;
     }
@@ -149,14 +141,14 @@ static int powernow_cpufreq_target(struc
 
 static int powernow_cpufreq_verify(struct cpufreq_policy *policy)
 {
-    struct powernow_cpufreq_data *data;
+    struct acpi_cpufreq_data *data;
     struct processor_performance *perf;
 
-    if (!policy || !(data = drv_data[policy->cpu]) ||
-        !processor_pminfo[policy->cpu])
+    if (!policy || !(data = per_cpu(cpufreq_data, policy->cpu)) ||
+        !per_cpu(processor_pminfo, policy->cpu))
         return -EINVAL;
 
-    perf = &processor_pminfo[policy->cpu]->perf;
+    perf = &per_cpu(processor_pminfo, policy->cpu)->perf;
 
     cpufreq_verify_within_limits(policy, 0, 
         perf->states[perf->platform_limit].core_frequency * 1000);
@@ -190,21 +182,21 @@ static int powernow_cpufreq_cpu_init(str
     unsigned int i;
     unsigned int valid_states = 0;
     unsigned int cpu = policy->cpu;
-    struct powernow_cpufreq_data *data;
+    struct acpi_cpufreq_data *data;
     unsigned int result = 0;
     struct processor_performance *perf;
     u32 max_hw_pstate;
     uint64_t msr_content;
     struct cpuinfo_x86 *c = &cpu_data[policy->cpu];
 
-    data = xmalloc(struct powernow_cpufreq_data);
+    data = xmalloc(struct acpi_cpufreq_data);
     if (!data)
         return -ENOMEM;
-    memset(data, 0, sizeof(struct powernow_cpufreq_data));
+    memset(data, 0, sizeof(struct acpi_cpufreq_data));
 
-    drv_data[cpu] = data;
+    per_cpu(cpufreq_data, cpu) = data;
 
-    data->acpi_data = &processor_pminfo[cpu]->perf;
+    data->acpi_data = &per_cpu(processor_pminfo, cpu)->perf;
 
     perf = data->acpi_data;
     policy->shared_type = perf->shared_type;
@@ -252,7 +244,6 @@ static int powernow_cpufreq_cpu_init(str
 
     policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
 
-    data->max_freq = perf->states[0].core_frequency * 1000;
     /* table init */
     for (i = 0; i < perf->state_count && i <= max_hw_pstate; i++) {
         if (i > 0 && perf->states[i].core_frequency >=
@@ -278,7 +269,7 @@ static int powernow_cpufreq_cpu_init(str
      * the first call to ->target() should result in us actually
      * writing something to the appropriate registers.
      */
-    data->resume = 1;
+    data->arch_cpu_flags |= ARCH_CPU_FLAG_RESUME;
 
     policy->cur = data->freq_table[i].frequency;
     return result;
@@ -287,17 +278,17 @@ err_freqfree:
     xfree(data->freq_table);
 err_unreg:
     xfree(data);
-    drv_data[cpu] = NULL;
+    per_cpu(cpufreq_data, cpu) = NULL;
 
     return result;
 }
 
 static int powernow_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 {
-    struct powernow_cpufreq_data *data = drv_data[policy->cpu];
+    struct acpi_cpufreq_data *data = per_cpu(cpufreq_data, policy->cpu);
 
     if (data) {
-        drv_data[policy->cpu] = NULL;
+        per_cpu(cpufreq_data, policy->cpu) = NULL;
         xfree(data->freq_table);
         xfree(data);
     }
diff -r 88fe9f780b3d -r eb601128d893 xen/drivers/acpi/pmstat.c
--- a/xen/drivers/acpi/pmstat.c	Thu May 26 17:16:47 2011 +0100
+++ b/xen/drivers/acpi/pmstat.c	Fri May 27 13:10:55 2011 +0200
@@ -57,7 +57,7 @@ int do_get_pm_info(struct xen_sysctl_get
 
     if ( !op || (op->cpuid >= NR_CPUS) || !cpu_online(op->cpuid) )
         return -EINVAL;
-    pmpt = processor_pminfo[op->cpuid];
+    pmpt = per_cpu(processor_pminfo, op->cpuid);
 
     switch ( op->type & PMSTAT_CATEGORY_MASK )
     {
@@ -203,7 +203,7 @@ static int get_cpufreq_para(struct xen_s
 
     if ( !op || !cpu_online(op->cpuid) )
         return -EINVAL;
-    pmpt = processor_pminfo[op->cpuid];
+    pmpt = per_cpu(processor_pminfo, op->cpuid);
     policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
 
     if ( !pmpt || !pmpt->perf.states ||
@@ -426,7 +426,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op
 
     if ( !op || !cpu_online(op->cpuid) )
         return -EINVAL;
-    pmpt = processor_pminfo[op->cpuid];
+    pmpt = per_cpu(processor_pminfo, op->cpuid);
 
     switch ( op->cmd & PM_PARA_CATEGORY_MASK )
     {
diff -r 88fe9f780b3d -r eb601128d893 xen/drivers/cpufreq/cpufreq.c
--- a/xen/drivers/cpufreq/cpufreq.c	Thu May 26 17:16:47 2011 +0100
+++ b/xen/drivers/cpufreq/cpufreq.c	Fri May 27 13:10:55 2011 +0200
@@ -91,12 +91,12 @@ int __init cpufreq_register_governor(str
 
 int cpufreq_limit_change(unsigned int cpu)
 {
-    struct processor_performance *perf = &processor_pminfo[cpu]->perf;
+    struct processor_performance *perf = &per_cpu(processor_pminfo, cpu)->perf;
     struct cpufreq_policy *data;
     struct cpufreq_policy policy;
 
     if (!cpu_online(cpu) || !(data = per_cpu(cpufreq_cpu_policy, cpu)) ||
-        !processor_pminfo[cpu])
+        !per_cpu(processor_pminfo, cpu))
         return -ENODEV;
 
     if (perf->platform_limit >= perf->state_count)
@@ -120,10 +120,10 @@ int cpufreq_add_cpu(unsigned int cpu)
     struct cpufreq_dom *cpufreq_dom = NULL;
     struct cpufreq_policy new_policy;
     struct cpufreq_policy *policy;
-    struct processor_performance *perf = &processor_pminfo[cpu]->perf;
+    struct processor_performance *perf = &per_cpu(processor_pminfo, cpu)->perf;
 
     /* to protect the case when Px was not controlled by xen */
-    if (!processor_pminfo[cpu]      ||
+    if (!per_cpu(processor_pminfo, cpu)      ||
         !(perf->init & XEN_PX_INIT) ||
         !cpu_online(cpu))
         return -EINVAL;
@@ -159,17 +159,17 @@ int cpufreq_add_cpu(unsigned int cpu)
         /* domain sanity check under whatever coordination type */
         firstcpu = first_cpu(cpufreq_dom->map);
         if ((perf->domain_info.coord_type !=
-            processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
+            per_cpu(processor_pminfo, firstcpu)->perf.domain_info.coord_type) ||
             (perf->domain_info.num_processors !=
-            processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
+            per_cpu(processor_pminfo, firstcpu)->perf.domain_info.num_processors)) {
 
             printk(KERN_WARNING "cpufreq fail to add CPU%d:"
                    "incorrect _PSD(%"PRIu64":%"PRIu64"), "
                    "expect(%"PRIu64"/%"PRIu64")\n",
                    cpu, perf->domain_info.coord_type,
                    perf->domain_info.num_processors,
-                   processor_pminfo[firstcpu]->perf.domain_info.coord_type,
-                   processor_pminfo[firstcpu]->perf.domain_info.num_processors
+                   per_cpu(processor_pminfo, firstcpu)->perf.domain_info.coord_type,
+                   per_cpu(processor_pminfo, firstcpu)->perf.domain_info.num_processors
                 );
             return -EINVAL;
         }
@@ -261,10 +261,10 @@ int cpufreq_del_cpu(unsigned int cpu)
     struct list_head *pos;
     struct cpufreq_dom *cpufreq_dom = NULL;
     struct cpufreq_policy *policy;
-    struct processor_performance *perf = &processor_pminfo[cpu]->perf;
+    struct processor_performance *perf = &per_cpu(processor_pminfo, cpu)->perf;
 
     /* to protect the case when Px was not controlled by xen */
-    if (!processor_pminfo[cpu]      ||
+    if (!per_cpu(processor_pminfo, cpu)      ||
         !(perf->init & XEN_PX_INIT) ||
         !cpu_online(cpu))
         return -EINVAL;
@@ -371,7 +371,7 @@ int set_px_pminfo(uint32_t acpi_id, stru
         printk("Set CPU acpi_id(%d) cpuid(%d) Px State info:\n",
                acpi_id, cpuid);
 
-    pmpt = processor_pminfo[cpuid];
+    pmpt = per_cpu(processor_pminfo, cpuid);
     if ( !pmpt )
     {
         pmpt = xmalloc(struct processor_pminfo);
@@ -381,7 +381,7 @@ int set_px_pminfo(uint32_t acpi_id, stru
             goto out;
         }
         memset(pmpt, 0, sizeof(*pmpt));
-        processor_pminfo[cpuid] = pmpt;
+        per_cpu(processor_pminfo, cpuid) = pmpt;
     }
     pxpt = &pmpt->perf;
     pmpt->acpi_id = acpi_id;
diff -r 88fe9f780b3d -r eb601128d893 xen/drivers/cpufreq/cpufreq_ondemand.c
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c	Thu May 26 17:16:47 2011 +0100
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c	Fri May 27 13:10:55 2011 +0200
@@ -194,7 +194,7 @@ static void dbs_timer_init(struct cpu_db
 
     set_timer(&per_cpu(dbs_timer, dbs_info->cpu), NOW()+dbs_tuners_ins.sampling_rate);
 
-    if ( processor_pminfo[dbs_info->cpu]->perf.shared_type
+    if ( per_cpu(processor_pminfo, dbs_info->cpu)->perf.shared_type
             == CPUFREQ_SHARED_TYPE_HW )
     {
         dbs_info->stoppable = 1;
diff -r 88fe9f780b3d -r eb601128d893 xen/drivers/cpufreq/utility.c
--- a/xen/drivers/cpufreq/utility.c	Thu May 26 17:16:47 2011 +0100
+++ b/xen/drivers/cpufreq/utility.c	Fri May 27 13:10:55 2011 +0200
@@ -33,7 +33,7 @@
 #include <public/sysctl.h>
 
 struct cpufreq_driver   *cpufreq_driver;
-struct processor_pminfo *__read_mostly processor_pminfo[NR_CPUS];
+DEFINE_PER_CPU_READ_MOSTLY(struct processor_pminfo *, processor_pminfo);
 DEFINE_PER_CPU_READ_MOSTLY(struct cpufreq_policy *, cpufreq_cpu_policy);
 
 DEFINE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
@@ -64,7 +64,7 @@ void cpufreq_statistic_update(unsigned i
 void cpufreq_statistic_update(unsigned int cpu, uint8_t from, uint8_t to)
 {
     struct pm_px *pxpt;
-    struct processor_pminfo *pmpt = processor_pminfo[cpu];
+    struct processor_pminfo *pmpt = per_cpu(processor_pminfo, cpu);
     spinlock_t *cpufreq_statistic_lock = 
                &per_cpu(cpufreq_statistic_lock, cpu);
 
@@ -91,7 +91,7 @@ int cpufreq_statistic_init(unsigned int 
 {
     uint32_t i, count;
     struct pm_px *pxpt;
-    const struct processor_pminfo *pmpt = processor_pminfo[cpuid];
+    const struct processor_pminfo *pmpt = per_cpu(processor_pminfo, cpuid);
     spinlock_t *cpufreq_statistic_lock = 
                           &per_cpu(cpufreq_statistic_lock, cpuid);
 
@@ -176,7 +176,7 @@ void cpufreq_statistic_reset(unsigned in
 {
     uint32_t i, j, count;
     struct pm_px *pxpt;
-    const struct processor_pminfo *pmpt = processor_pminfo[cpuid];
+    const struct processor_pminfo *pmpt = per_cpu(processor_pminfo, cpuid);
     spinlock_t *cpufreq_statistic_lock = 
                &per_cpu(cpufreq_statistic_lock, cpuid);
 
diff -r 88fe9f780b3d -r eb601128d893 xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h	Thu May 26 17:16:47 2011 +0100
+++ b/xen/include/acpi/cpufreq/cpufreq.h	Fri May 27 13:10:55 2011 +0200
@@ -29,8 +29,9 @@ struct acpi_cpufreq_data {
 struct acpi_cpufreq_data {
     struct processor_performance *acpi_data;
     struct cpufreq_frequency_table *freq_table;
-    unsigned int cpu_feature;
+    unsigned int arch_cpu_flags;
 };
+DECLARE_PER_CPU(struct acpi_cpufreq_data *, cpufreq_data);
 
 struct cpufreq_cpuinfo {
     unsigned int        max_freq;
diff -r 88fe9f780b3d -r eb601128d893 xen/include/acpi/cpufreq/processor_perf.h
--- a/xen/include/acpi/cpufreq/processor_perf.h	Thu May 26 17:16:47 2011 +0100
+++ b/xen/include/acpi/cpufreq/processor_perf.h	Fri May 27 13:10:55 2011 +0200
@@ -41,7 +41,7 @@ struct processor_pminfo {
     struct processor_performance    perf;
 };
 
-extern struct processor_pminfo *processor_pminfo[NR_CPUS];
+DECLARE_PER_CPU(struct processor_pminfo *, processor_pminfo);
 
 struct px_stat {
     uint8_t total;        /* total Px states */

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] use per-cpu variables in cpufreq
  2011-05-27 11:11 [PATCH] use per-cpu variables in cpufreq Juergen Gross
@ 2011-05-27 13:11 ` Keir Fraser
  2011-05-27 13:29   ` Juergen Gross
  2011-06-10 19:00 ` Langsdorf, Mark
  1 sibling, 1 reply; 13+ messages in thread
From: Keir Fraser @ 2011-05-27 13:11 UTC (permalink / raw)
  To: Juergen Gross, xen-devel

On 27/05/2011 12:11, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> The cpufreq driver used some local arrays indexed by cpu number. This patch
> replaces those arrays by per-cpu variables. The AMD and INTEL specific parts
> used different per-cpu data structures with nearly identical semantics.
> Fold the two structures into one by adding a generic architecture data item.

Xen's per-cpu data gets freed across cpu offline/online, whereas cpu-indexed
arrays of course do not. Will the cpufreq state be correctly handled across
offline/online if we switch to per-cpu vars?

 -- Keir

> Signed-off-by: juergen.gross@ts.fujitsu.com
> 
> 
> 8 files changed, 58 insertions(+), 66 deletions(-)
> xen/arch/x86/acpi/cpufreq/cpufreq.c       |   36 ++++++++++++------------
> xen/arch/x86/acpi/cpufreq/powernow.c      |   43 +++++++++++------------------
> xen/drivers/acpi/pmstat.c                 |    6 ++--
> xen/drivers/cpufreq/cpufreq.c             |   24 ++++++++--------
> xen/drivers/cpufreq/cpufreq_ondemand.c    |    2 -
> xen/drivers/cpufreq/utility.c             |    8 ++---
> xen/include/acpi/cpufreq/cpufreq.h        |    3 +-
> xen/include/acpi/cpufreq/processor_perf.h |    2 -
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] use per-cpu variables in cpufreq
  2011-05-27 13:11 ` Keir Fraser
@ 2011-05-27 13:29   ` Juergen Gross
  2011-05-28  7:52     ` Keir Fraser
  0 siblings, 1 reply; 13+ messages in thread
From: Juergen Gross @ 2011-05-27 13:29 UTC (permalink / raw)
  To: Keir Fraser; +Cc: xen-devel

On 05/27/11 15:11, Keir Fraser wrote:
> On 27/05/2011 12:11, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>
>> The cpufreq driver used some local arrays indexed by cpu number. This patch
>> replaces those arrays by per-cpu variables. The AMD and INTEL specific parts
>> used different per-cpu data structures with nearly identical semantics.
>> Fold the two structures into one by adding a generic architecture data item.
> Xen's per-cpu data gets freed across cpu offline/online, whereas cpu-indexed
> arrays of course do not. Will the cpufreq state be correctly handled across
> offline/online if we switch to per-cpu vars?

As far as I could see, yes. The data should only be used for cpus with
a valid acpid->cpuid translation, which is created when a cpu is going
online and destroyed when it is going offline again.
It would be nice, however, if the INTEL and/or AMD code owners could
give an ack on this...


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] use per-cpu variables in cpufreq
  2011-05-27 13:29   ` Juergen Gross
@ 2011-05-28  7:52     ` Keir Fraser
  2011-05-30  5:47       ` Juergen Gross
  2011-05-30  8:06       ` Tian, Kevin
  0 siblings, 2 replies; 13+ messages in thread
From: Keir Fraser @ 2011-05-28  7:52 UTC (permalink / raw)
  To: Juergen Gross; +Cc: Liu, Jinsong, xen-devel, mark.langsdorf

On 27/05/2011 14:29, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> On 05/27/11 15:11, Keir Fraser wrote:
>> On 27/05/2011 12:11, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>> 
>>> The cpufreq driver used some local arrays indexed by cpu number. This patch
>>> replaces those arrays by per-cpu variables. The AMD and INTEL specific parts
>>> used different per-cpu data structures with nearly identical semantics.
>>> Fold the two structures into one by adding a generic architecture data item.
>> Xen's per-cpu data gets freed across cpu offline/online, whereas cpu-indexed
>> arrays of course do not. Will the cpufreq state be correctly handled across
>> offline/online if we switch to per-cpu vars?
> 
> As far as I could see, yes. The data should only be used for cpus with
> a valid acpid->cpuid translation, which is created when a cpu is going
> online and destroyed when it is going offline again.

That simply isn't true. acpiid_to_apicid[] is populated during boot and
entries are never destroyed.

Specifically, my fear is that this data gets pushed into the hypervisor
once-only during dom0 boot (via XENPF_set_processor_pminfo). If it is freed
during processor offline, we lose it forever and have no power management
when/if a CPU is brought back online. Worse I suspect your patch as it is
will crash if some CPUs are offline during boot as you'll deference their
per_cpu area which doesn't actually exist unless a CPU is online. You can
test this for yourself by adding a maxcpus=1 boot parameter for Xen.

The folding of the Intel/AMD structures might still be interesting, and
probably belongs as a separate patch anyway.

Cc'ing Intel and AMD guys to confirm this.

 -- Keir

> It would be nice, however, if the INTEL and/or AMD code owners could
> give an ack on this...
> 
> 
> Juergen

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] use per-cpu variables in cpufreq
  2011-05-28  7:52     ` Keir Fraser
@ 2011-05-30  5:47       ` Juergen Gross
  2011-05-30  9:45         ` Keir Fraser
  2011-05-30  8:06       ` Tian, Kevin
  1 sibling, 1 reply; 13+ messages in thread
From: Juergen Gross @ 2011-05-30  5:47 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Liu, Jinsong, xen-devel, mark.langsdorf

On 05/28/11 09:52, Keir Fraser wrote:
> On 27/05/2011 14:29, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>
>> On 05/27/11 15:11, Keir Fraser wrote:
>>> On 27/05/2011 12:11, "Juergen Gross"<juergen.gross@ts.fujitsu.com>   wrote:
>>>
>>>> The cpufreq driver used some local arrays indexed by cpu number. This patch
>>>> replaces those arrays by per-cpu variables. The AMD and INTEL specific parts
>>>> used different per-cpu data structures with nearly identical semantics.
>>>> Fold the two structures into one by adding a generic architecture data item.
>>> Xen's per-cpu data gets freed across cpu offline/online, whereas cpu-indexed
>>> arrays of course do not. Will the cpufreq state be correctly handled across
>>> offline/online if we switch to per-cpu vars?
>> As far as I could see, yes. The data should only be used for cpus with
>> a valid acpid->cpuid translation, which is created when a cpu is going
>> online and destroyed when it is going offline again.
> That simply isn't true. acpiid_to_apicid[] is populated during boot and
> entries are never destroyed.

Hmm, checked it again and saw you are right. Don't know where I've
been  fooled.

> Specifically, my fear is that this data gets pushed into the hypervisor
> once-only during dom0 boot (via XENPF_set_processor_pminfo). If it is freed
> during processor offline, we lose it forever and have no power management
> when/if a CPU is brought back online. Worse I suspect your patch as it is
> will crash if some CPUs are offline during boot as you'll deference their
> per_cpu area which doesn't actually exist unless a CPU is online. You can
> test this for yourself by adding a maxcpus=1 boot parameter for Xen.

Indeed.

Just to understand this completely:
So when is this info set up for hot-plugged cpus? And what happens if
a cpu module is removed and later replaced by another module with
more cores (or threads) than the original one?
I think the processor pminfo should be set in this case during the hotplug
handling.

> The folding of the Intel/AMD structures might still be interesting, and
> probably belongs as a separate patch anyway.
>
> Cc'ing Intel and AMD guys to confirm this.

Okay, I'm waiting for their opinion.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [PATCH] use per-cpu variables in cpufreq
  2011-05-28  7:52     ` Keir Fraser
  2011-05-30  5:47       ` Juergen Gross
@ 2011-05-30  8:06       ` Tian, Kevin
  2011-05-30 15:33         ` Liu, Jinsong
  1 sibling, 1 reply; 13+ messages in thread
From: Tian, Kevin @ 2011-05-30  8:06 UTC (permalink / raw)
  To: Keir Fraser, Juergen Gross; +Cc: Liu, Jinsong, xen-devel, mark.langsdorf

> From: Keir Fraser
> Sent: Saturday, May 28, 2011 3:53 PM
> 
> On 27/05/2011 14:29, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
> 
> > On 05/27/11 15:11, Keir Fraser wrote:
> >> On 27/05/2011 12:11, "Juergen Gross"<juergen.gross@ts.fujitsu.com>
> wrote:
> >>
> >>> The cpufreq driver used some local arrays indexed by cpu number. This
> patch
> >>> replaces those arrays by per-cpu variables. The AMD and INTEL specific
> parts
> >>> used different per-cpu data structures with nearly identical semantics.
> >>> Fold the two structures into one by adding a generic architecture data
> item.
> >> Xen's per-cpu data gets freed across cpu offline/online, whereas
> cpu-indexed
> >> arrays of course do not. Will the cpufreq state be correctly handled across
> >> offline/online if we switch to per-cpu vars?
> >
> > As far as I could see, yes. The data should only be used for cpus with
> > a valid acpid->cpuid translation, which is created when a cpu is going
> > online and destroyed when it is going offline again.
> 
> That simply isn't true. acpiid_to_apicid[] is populated during boot and
> entries are never destroyed.
> 
> Specifically, my fear is that this data gets pushed into the hypervisor
> once-only during dom0 boot (via XENPF_set_processor_pminfo). If it is freed
> during processor offline, we lose it forever and have no power management

exactly. Suppose many of those arrays are only referenced at driver initialization
phase, or not referenced frequently. Not to use percpu variable here is just
fine unless you find some actual hot lines which then can be fixed accordingly.

Thanks
Kevin

> when/if a CPU is brought back online. Worse I suspect your patch as it is
> will crash if some CPUs are offline during boot as you'll deference their
> per_cpu area which doesn't actually exist unless a CPU is online. You can
> test this for yourself by adding a maxcpus=1 boot parameter for Xen.
> 
> The folding of the Intel/AMD structures might still be interesting, and
> probably belongs as a separate patch anyway.
> 
> Cc'ing Intel and AMD guys to confirm this.
> 
>  -- Keir
> 
> > It would be nice, however, if the INTEL and/or AMD code owners could
> > give an ack on this...
> >
> >
> > Juergen
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] use per-cpu variables in cpufreq
  2011-05-30  5:47       ` Juergen Gross
@ 2011-05-30  9:45         ` Keir Fraser
  2011-05-31  1:51           ` Tian, Kevin
  0 siblings, 1 reply; 13+ messages in thread
From: Keir Fraser @ 2011-05-30  9:45 UTC (permalink / raw)
  To: Juergen Gross; +Cc: Liu, Jinsong, xen-devel, mark.langsdorf

On 30/05/2011 06:47, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

>> Specifically, my fear is that this data gets pushed into the hypervisor
>> once-only during dom0 boot (via XENPF_set_processor_pminfo). If it is freed
>> during processor offline, we lose it forever and have no power management
>> when/if a CPU is brought back online. Worse I suspect your patch as it is
>> will crash if some CPUs are offline during boot as you'll deference their
>> per_cpu area which doesn't actually exist unless a CPU is online. You can
>> test this for yourself by adding a maxcpus=1 boot parameter for Xen.
> 
> Indeed.
> 
> Just to understand this completely:
> So when is this info set up for hot-plugged cpus? And what happens if
> a cpu module is removed and later replaced by another module with
> more cores (or threads) than the original one?
> I think the processor pminfo should be set in this case during the hotplug
> handling.

Well, there is a difference between logical and physical cpu hotplug. Xen is
capable of bringing CPUs online and offline without them actually being
physically plugged/unplugged from the mainboard. Indeed our physical hotplug
support is relatively new and I would suspect not much used (and it supports
only physical insertion, not removal!).

Frankly there are a number of questions around CPUs that are physically
plugged in after boot:
 * How does per-CPU ACPI state like PM info get set up?
 * In a system where TSCs are otherwise all perfectly in sync, does the
firmware help us by setting up the new CPUs' TSCs likewise?

I don't actually know the answers to these questions. Maybe dom0 ACPI does
get triggered on physical insertion and knows how to set up PM stuff?

So, when I say CPU hotplug, or online/offline, I'm generally focussing on
logical hotplug only still at the moment. Physical hotplug is a black art
with question marks hanging over it for me. ;-)

 -- Keir

>> The folding of the Intel/AMD structures might still be interesting, and
>> probably belongs as a separate patch anyway.
>> 
>> Cc'ing Intel and AMD guys to confirm this.
> 
> Okay, I'm waiting for their opinion.
> 
> 
> Juergen

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [PATCH] use per-cpu variables in cpufreq
  2011-05-30  8:06       ` Tian, Kevin
@ 2011-05-30 15:33         ` Liu, Jinsong
  0 siblings, 0 replies; 13+ messages in thread
From: Liu, Jinsong @ 2011-05-30 15:33 UTC (permalink / raw)
  To: Tian, Kevin, Keir Fraser, Juergen Gross; +Cc: xen-devel, mark.langsdorf

Tian, Kevin wrote:
>> From: Keir Fraser
>> Sent: Saturday, May 28, 2011 3:53 PM
>> 
>> On 27/05/2011 14:29, "Juergen Gross" <juergen.gross@ts.fujitsu.com>
>> wrote: 
>> 
>>> On 05/27/11 15:11, Keir Fraser wrote:
>>>> On 27/05/2011 12:11, "Juergen Gross"<juergen.gross@ts.fujitsu.com>
>>>> wrote: 
>>>> 
>>>>> The cpufreq driver used some local arrays indexed by cpu number.
>>>>> This patch replaces those arrays by per-cpu variables. The AMD
>>>>> and INTEL specific parts used different per-cpu data structures
>>>>> with nearly identical semantics. Fold the two structures into one
>>>>> by adding a generic architecture data 
>> item.
>>>> Xen's per-cpu data gets freed across cpu offline/online, whereas
>>>> cpu-indexed arrays of course do not. Will the cpufreq state be
>>>> correctly handled across offline/online if we switch to per-cpu
>>>> vars? 
>>> 
>>> As far as I could see, yes. The data should only be used for cpus
>>> with a valid acpid->cpuid translation, which is created when a cpu
>>> is going online and destroyed when it is going offline again.
>> 
>> That simply isn't true. acpiid_to_apicid[] is populated during boot
>> and entries are never destroyed. 
>> 
>> Specifically, my fear is that this data gets pushed into the
>> hypervisor once-only during dom0 boot (via
>> XENPF_set_processor_pminfo). If it is freed during processor
>> offline, we lose it forever and have no power management 
> 
> exactly. Suppose many of those arrays are only referenced at driver
> initialization phase, or not referenced frequently. Not to use percpu
> variable here is just 
> fine unless you find some actual hot lines which then can be fixed
> accordingly. 
> 
> Thanks
> Kevin

Agree Keir and Kevin.
Static array during boot maybe simple and reliable.

> 
>> when/if a CPU is brought back online. Worse I suspect your patch as
>> it is will crash if some CPUs are offline during boot as you'll
>> deference their per_cpu area which doesn't actually exist unless a
>> CPU is online. You can test this for yourself by adding a maxcpus=1
>> boot parameter for Xen. 
>> 
>> The folding of the Intel/AMD structures might still be interesting,
>> and probably belongs as a separate patch anyway.
>> 
>> Cc'ing Intel and AMD guys to confirm this.
>> 
>>  -- Keir
>> 
>>> It would be nice, however, if the INTEL and/or AMD code owners
>>> could give an ack on this... 

It's fine to me to merge acpi_cpufreq_data and powernow_cpufreq_data.
In fact acpi_cpufreq_data can be commonly used by both Intel and AMD cpufreq logic. 
I didn't image the benefit of adding a similar struct powernow_cpufreq_data.

Thanks,
Jinsong

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [PATCH] use per-cpu variables in cpufreq
  2011-05-30  9:45         ` Keir Fraser
@ 2011-05-31  1:51           ` Tian, Kevin
  2011-05-31  7:31             ` Keir Fraser
  2011-05-31  7:37             ` Liu, Jinsong
  0 siblings, 2 replies; 13+ messages in thread
From: Tian, Kevin @ 2011-05-31  1:51 UTC (permalink / raw)
  To: Keir Fraser, Juergen Gross; +Cc: Liu, Jinsong, xen-devel, mark.langsdorf

> From: Keir Fraser
> Sent: Monday, May 30, 2011 5:45 PM
> 
> On 30/05/2011 06:47, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
> 
> >> Specifically, my fear is that this data gets pushed into the hypervisor
> >> once-only during dom0 boot (via XENPF_set_processor_pminfo). If it is freed
> >> during processor offline, we lose it forever and have no power management
> >> when/if a CPU is brought back online. Worse I suspect your patch as it is
> >> will crash if some CPUs are offline during boot as you'll deference their
> >> per_cpu area which doesn't actually exist unless a CPU is online. You can
> >> test this for yourself by adding a maxcpus=1 boot parameter for Xen.
> >
> > Indeed.
> >
> > Just to understand this completely:
> > So when is this info set up for hot-plugged cpus? And what happens if
> > a cpu module is removed and later replaced by another module with
> > more cores (or threads) than the original one?
> > I think the processor pminfo should be set in this case during the hotplug
> > handling.
> 
> Well, there is a difference between logical and physical cpu hotplug. Xen is
> capable of bringing CPUs online and offline without them actually being
> physically plugged/unplugged from the mainboard. Indeed our physical hotplug
> support is relatively new and I would suspect not much used (and it supports
> only physical insertion, not removal!).
> 
> Frankly there are a number of questions around CPUs that are physically
> plugged in after boot:
>  * How does per-CPU ACPI state like PM info get set up?

A hotplug-able cpu still has an ACPI CPU object in DSDT table, which may exist
in original DSDT table, or dynamically loaded later upon hotplug event. Once
dom0 ACPI recognizes a new CPU object, it will notify Xen about discovered
pm information.

>  * In a system where TSCs are otherwise all perfectly in sync, does the
> firmware help us by setting up the new CPUs' TSCs likewise?

Here what firmware can do is similar to what Xen can do, which can't ensure
you a truly synchronized TSC on new CPU.

Thanks
Kevin

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] use per-cpu variables in cpufreq
  2011-05-31  1:51           ` Tian, Kevin
@ 2011-05-31  7:31             ` Keir Fraser
  2011-05-31  7:37             ` Liu, Jinsong
  1 sibling, 0 replies; 13+ messages in thread
From: Keir Fraser @ 2011-05-31  7:31 UTC (permalink / raw)
  To: Tian, Kevin, Juergen Gross; +Cc: Liu, Jinsong, xen-devel, mark.langsdorf

On 31/05/2011 02:51, "Tian, Kevin" <kevin.tian@intel.com> wrote:

>> 
>> Well, there is a difference between logical and physical cpu hotplug. Xen is
>> capable of bringing CPUs online and offline without them actually being
>> physically plugged/unplugged from the mainboard. Indeed our physical hotplug
>> support is relatively new and I would suspect not much used (and it supports
>> only physical insertion, not removal!).
>> 
>> Frankly there are a number of questions around CPUs that are physically
>> plugged in after boot:
>>  * How does per-CPU ACPI state like PM info get set up?
> 
> A hotplug-able cpu still has an ACPI CPU object in DSDT table, which may exist
> in original DSDT table, or dynamically loaded later upon hotplug event. Once
> dom0 ACPI recognizes a new CPU object, it will notify Xen about discovered
> pm information.

Thanks. I guessed there was probably some magic for this.

 -- Keir

>>  * In a system where TSCs are otherwise all perfectly in sync, does the
>> firmware help us by setting up the new CPUs' TSCs likewise?
> 
> Here what firmware can do is similar to what Xen can do, which can't ensure
> you a truly synchronized TSC on new CPU.
> 
> Thanks
> Kevin
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [PATCH] use per-cpu variables in cpufreq
  2011-05-31  1:51           ` Tian, Kevin
  2011-05-31  7:31             ` Keir Fraser
@ 2011-05-31  7:37             ` Liu, Jinsong
  1 sibling, 0 replies; 13+ messages in thread
From: Liu, Jinsong @ 2011-05-31  7:37 UTC (permalink / raw)
  To: Tian, Kevin, Keir Fraser, Juergen Gross; +Cc: xen-devel, mark.langsdorf

Tian, Kevin wrote:
>> From: Keir Fraser
>> Sent: Monday, May 30, 2011 5:45 PM
>> 
>> On 30/05/2011 06:47, "Juergen Gross" <juergen.gross@ts.fujitsu.com>
>> wrote: 
>> 
>>>> Specifically, my fear is that this data gets pushed into the
>>>> hypervisor once-only during dom0 boot (via
>>>> XENPF_set_processor_pminfo). If it is freed during processor
>>>> offline, we lose it forever and have no power management when/if a
>>>> CPU is brought back online. Worse I suspect your patch as it is
>>>> will crash if some CPUs are offline during boot as you'll
>>>> deference their per_cpu area which doesn't actually exist unless a
>>>> CPU is online. You can test this for yourself by adding a
>>>> maxcpus=1 boot parameter for Xen.  
>>> 
>>> Indeed.
>>> 
>>> Just to understand this completely:
>>> So when is this info set up for hot-plugged cpus? And what happens
>>> if 
>>> a cpu module is removed and later replaced by another module with
>>> more cores (or threads) than the original one?
>>> I think the processor pminfo should be set in this case during the
>>> hotplug handling.
>> 
>> Well, there is a difference between logical and physical cpu
>> hotplug. Xen is capable of bringing CPUs online and offline without
>> them actually being physically plugged/unplugged from the mainboard.
>> Indeed our physical hotplug support is relatively new and I would
>> suspect not much used (and it supports only physical insertion, not
>> removal!). 
>> 
>> Frankly there are a number of questions around CPUs that are
>>  physically plugged in after boot: * How does per-CPU ACPI state
>> like PM info get set up? 
> 
> A hotplug-able cpu still has an ACPI CPU object in DSDT table, which
> may exist in original DSDT table, or dynamically loaded later upon
> hotplug event. Once dom0 ACPI recognizes a new CPU object, it will
> notify Xen about discovered 
> pm information.

Yes. When cpu hotplug, a sci will triggerred dom0 ospm which will then evaluate sci, and then call related acpi control method;
control method will again notify() dom0 ospm which cpu what happened.
dom0 got the notifier depend on the way acpi difine cpu as \_SB or \_PR object, then continue hypercall hypervisor ...

Thanks,
Jinsong

> 
>>  * In a system where TSCs are otherwise all perfectly in sync, does
>> the firmware help us by setting up the new CPUs' TSCs likewise?
> 
> Here what firmware can do is similar to what Xen can do, which can't
> ensure you a truly synchronized TSC on new CPU.
> 
> Thanks
> Kevin

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [PATCH] use per-cpu variables in cpufreq
  2011-05-27 11:11 [PATCH] use per-cpu variables in cpufreq Juergen Gross
  2011-05-27 13:11 ` Keir Fraser
@ 2011-06-10 19:00 ` Langsdorf, Mark
  2011-06-14  9:04   ` Juergen Gross
  1 sibling, 1 reply; 13+ messages in thread
From: Langsdorf, Mark @ 2011-06-10 19:00 UTC (permalink / raw)
  To: 'Juergen Gross', xen-devel

After Keir's comments downthread, are we going to see a 
fresh patch for review?

--Mark Langsdorf
Operating System Research Center
AMD

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Juergen Gross
> Sent: Friday, May 27, 2011 6:11 AM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
> 
> The cpufreq driver used some local arrays indexed by cpu 
> number. This patch
> replaces those arrays by per-cpu variables. The AMD and INTEL 
> specific parts
> used different per-cpu data structures with nearly identical 
> semantics.
> Fold the two structures into one by adding a generic 
> architecture data item.
> 
> Signed-off-by: juergen.gross@ts.fujitsu.com
> 
> 
> 8 files changed, 58 insertions(+), 66 deletions(-)
> xen/arch/x86/acpi/cpufreq/cpufreq.c       |   36 
> ++++++++++++------------
> xen/arch/x86/acpi/cpufreq/powernow.c      |   43 
> +++++++++++------------------
> xen/drivers/acpi/pmstat.c                 |    6 ++--
> xen/drivers/cpufreq/cpufreq.c             |   24 ++++++++--------
> xen/drivers/cpufreq/cpufreq_ondemand.c    |    2 -
> xen/drivers/cpufreq/utility.c             |    8 ++---
> xen/include/acpi/cpufreq/cpufreq.h        |    3 +-
> xen/include/acpi/cpufreq/processor_perf.h |    2 -
> 
> 
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] use per-cpu variables in cpufreq
  2011-06-10 19:00 ` Langsdorf, Mark
@ 2011-06-14  9:04   ` Juergen Gross
  0 siblings, 0 replies; 13+ messages in thread
From: Juergen Gross @ 2011-06-14  9:04 UTC (permalink / raw)
  To: Langsdorf, Mark; +Cc: xen-devel

On 06/10/11 21:00, Langsdorf, Mark wrote:
> After Keir's comments downthread, are we going to see a
> fresh patch for review?

Yes, I think I'll have some time this week to do this.
Sorry for the delay...


Juergen

> --Mark Langsdorf
> Operating System Research Center
> AMD
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
>> Juergen Gross
>> Sent: Friday, May 27, 2011 6:11 AM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
>>
>> The cpufreq driver used some local arrays indexed by cpu
>> number. This patch
>> replaces those arrays by per-cpu variables. The AMD and INTEL
>> specific parts
>> used different per-cpu data structures with nearly identical
>> semantics.
>> Fold the two structures into one by adding a generic
>> architecture data item.
>>
>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>
>>
>> 8 files changed, 58 insertions(+), 66 deletions(-)
>> xen/arch/x86/acpi/cpufreq/cpufreq.c       |   36
>> ++++++++++++------------
>> xen/arch/x86/acpi/cpufreq/powernow.c      |   43
>> +++++++++++------------------
>> xen/drivers/acpi/pmstat.c                 |    6 ++--
>> xen/drivers/cpufreq/cpufreq.c             |   24 ++++++++--------
>> xen/drivers/cpufreq/cpufreq_ondemand.c    |    2 -
>> xen/drivers/cpufreq/utility.c             |    8 ++---
>> xen/include/acpi/cpufreq/cpufreq.h        |    3 +-
>> xen/include/acpi/cpufreq/processor_perf.h |    2 -
>>
>>
>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2011-06-14  9:04 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-27 11:11 [PATCH] use per-cpu variables in cpufreq Juergen Gross
2011-05-27 13:11 ` Keir Fraser
2011-05-27 13:29   ` Juergen Gross
2011-05-28  7:52     ` Keir Fraser
2011-05-30  5:47       ` Juergen Gross
2011-05-30  9:45         ` Keir Fraser
2011-05-31  1:51           ` Tian, Kevin
2011-05-31  7:31             ` Keir Fraser
2011-05-31  7:37             ` Liu, Jinsong
2011-05-30  8:06       ` Tian, Kevin
2011-05-30 15:33         ` Liu, Jinsong
2011-06-10 19:00 ` Langsdorf, Mark
2011-06-14  9:04   ` Juergen Gross

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.