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
Keir Fraser
2011-May-27 13:11 UTC
Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2011-May-27 13:29 UTC
Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-28 07:52 UTC
Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2011-May-30 05:47 UTC
Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-May-30 08:06 UTC
RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
> 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 managementexactly. 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-30 09:45 UTC
Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liu, Jinsong
2011-May-30 15:33 UTC
RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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 > KevinAgree 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-May-31 01:51 UTC
RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-31 07:31 UTC
Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liu, Jinsong
2011-May-31 07:37 UTC
RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Langsdorf, Mark
2011-Jun-10 19:00 UTC
RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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 - > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2011-Jun-14 09:04 UTC
Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel