ACPI state change corrections
PATCH 1/1 ACPI state change corrections
Doing an ACPI state change with not all cpus in cpupool 0 will currently crash the hypervisor.
Patch 1 relaxes cpupool cpu offlining handling to allow offlining a cpu in
any cpupool if no lack of ressources is detected
Patch 2 prohibits migrating a vcpu to another cpu if it is paused
6 files changed, 144 insertions(+), 33 deletions(-) xen/arch/x86/smpboot.c | 2 - xen/common/cpupool.c | 85 +++++++++++++++++++++++++++++++++++++++----- xen/common/domain.c | 4 +- xen/common/schedule.c | 83 +++++++++++++++++++++++++++++++----------- xen/include/xen/sched-if.h | 1 xen/include/xen/sched.h | 2 +
PATCH 1/1 Allow ACPI state change with active cpupools
Changing the ACPI state (e.g. power off) while not all cpus are in cpupool 0 will currently crash the hypervisor during disabling the other cpus. Up to now only cpus in Pool-0 were allowed to go offline. There is no reason why a cpu in another cpupool can't be taken offline if there are still other cpus available in that cpupool.
As disabling the cpus for an ACPI state change is only a temporary measure (if not poweroff, of course) and all domains are paused in this case, there is no reason to reject removing the last cpu from a cpupool if only paused domains are in this cpupool.
The cpus taken offline from a cpupool will be still associated with that cpupool to enable adding them automatically when they are becoming online again.
4 files changed, 80 insertions(+), 9 deletions(-) xen/arch/x86/smpboot.c | 2 - xen/common/cpupool.c | 85 +++++++++++++++++++++++++++++++++++++++----- xen/include/xen/sched-if.h | 1 xen/include/xen/sched.h | 1
# HG changeset patch
# User Juergen Gross <[email protected]> # Date 1332404504 -3600
# Node ID 12d8bb0e02edf68b4a0526a2989a660218535fcb # Parent 4e1d091d10d83130842170cd61f1194e5459f2aa Allow ACPI state change with active cpupools
Changing the ACPI state (e.g. power off) while not all cpus are in cpupool 0 will currently crash the hypervisor during disabling the other cpus. Up to now only cpus in Pool-0 were allowed to go offline. There is no reason why a cpu in another cpupool can't be taken offline if there are still other cpus available in that cpupool.
As disabling the cpus for an ACPI state change is only a temporary measure (if not poweroff, of course) and all domains are paused in this case, there is no reason to reject removing the last cpu from a cpupool if only paused domains are in this cpupool.
The cpus taken offline from a cpupool will be still associated with that cpupool to enable adding them automatically when they are becoming online again.
xen/arch/x86/smpboot.c +1 -1
@@ -863,7 +863,7 @@ void __cpu_disable(void)remove_siblinginfo (cpu);/* It's now safe to remove this processor from the online map */ -cpumask_clear_cpu (cpu, cpupool0->cpu_valid); +cpupool_disable_cpu (cpu);cpumask_clear_cpu (cpu, &cpu_online_map);fixup_irqs ();
xen/common/cpupool.c +77 -8
135 lines not on this page · raw message
xen/include/xen/sched-if.h +1 -0
@@ -199,6 +199,7 @@ struct cpupool {int cpupool_id;cpumask_var_t cpu_valid;/* all cpus assigned to pool */ +cpumask_var_t cpu_offline;/* cpus from pool taken offline */ struct cpupool *next;unsigned int n_dom;struct scheduler *sched;
xen/include/xen/sched.h +1 -0
@@ -715,6 +715,7 @@ int cpupool_do_sysctl(struct xen_sysctl_int cpupool_do_sysctl (struct xen_sysctl_cpupool_op *op);void schedule_dump (struct cpupool *c);extern void dump_runq (unsigned char key); +void cpupool_disable_cpu (unsigned int cpu);#define num_cpupool_cpus (c) cpumask_weight((c)->cpu_valid)
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Re: [PATCH 1 of 2] Allow ACPI state change with active cpupools
xen/common/cpupool.c void cpupool_rm_domain(struct domain *d) · line 438
Quoted 11 lines
Quoted 1 line
Quoted 1 line · Juergen Gross
static void
cpupool_cpu_add(unsigned int cpu)
{xen/common/cpupool.c +5
-0+struct cpupool **c; +spin_lock (&cpupool_lock);cpumask_clear_cpu (cpu, &cpupool_locked_cpus);cpumask_set_cpu (cpu, &cpupool_free_cpus); +if (cpumask_test_cpu (cpu, &cpupool_free_offline_cpus) ) + { +cpumask_clear_cpu (cpu, &cpupool_free_offline_cpus);
cpumask_test_and_clear_cpu()
xen/common/cpupool.c void cpupool_rm_domain(struct domain *d) · line 445
Quoted 7 lines
xen/common/cpupool.c +7
-0+ goto out; + } +for_each_cpupool (c) + { +if (cpumask_test_cpu (cpu, (*c)->cpu_offline) ) + { +cpumask_clear_cpu (cpu, (*c)->cpu_offline);
Here too.
Quoted 9 lines
xen/common/cpupool.c +7
-0+cpupool_assign_cpu_locked (*c, cpu); + goto out; + } + }cpupool_assign_cpu_locked (cpupool0, cpu); +void cpupool_disable_cpu (unsigned int cpu) +{ +struct cpupool *c;
xen/common/cpupool.c int cpupool_do_sysctl(struct xen_sysctl_ · line 664
Quoted 10 lines
xen/common/cpupool.c +10
-0+ + c =per_cpu (cpupool, cpu); +if ( c ==NULL ) + { +cpumask_clear_cpu (cpu, &cpupool_free_cpus); +cpumask_set_cpu (cpu, &cpupool_free_offline_cpus); + } +else if (cpumask_test_cpu (cpu, c->cpu_valid) ) + { +cpumask_clear_cpu (cpu, c->cpu_valid);
And once more.
xen/common/cpupool.c int cpupool_do_sysctl(struct xen_sysctl_ · line 667
Quoted 3 lines
xen/common/cpupool.c +3
-0+cpumask_set_cpu (cpu, c->cpu_offline); + } +}
Jan
PATCH 1/1 Avoid vcpu migration of paused vcpus
In reply to Juergen GrossCurrently offlining a cpu will migrate all vcpus which were active on that cpu to another one, possibly breaking existing cpu affinities.
In case of an ACPI state change the cpus are taken offline and online later (if not poweroff) while all domains are paused. There is no reason to migrate the vcpus during offlining the cpus, as the cpus will be available again when the domains are being unpaused.
This patch defers the migration check in case of paused vcpus or domains by adding vcpu_arouse() to wake up a vcpu and check whether it must be migrated to another cpu.
3 files changed, 64 insertions(+), 24 deletions(-) xen/common/domain.c | 4 +- xen/common/schedule.c | 83 ++++++++++++++++++++++++++++++++++------------- xen/include/xen/sched.h | 1
# HG changeset patch
# User Juergen Gross <[email protected]> # Date 1332404507 -3600
# Node ID 932dc3987e3dac816d51e49861ab2ff21e8228b5 # Parent 12d8bb0e02edf68b4a0526a2989a660218535fcb Avoid vcpu migration of paused vcpus
Currently offlining a cpu will migrate all vcpus which were active on that cpu to another one, possibly breaking existing cpu affinities.
In case of an ACPI state change the cpus are taken offline and online later (if not poweroff) while all domains are paused. There is no reason to migrate the vcpus during offlining the cpus, as the cpus will be available again when the domains are being unpaused.
This patch defers the migration check in case of paused vcpus or domains by adding vcpu_arouse() to wake up a vcpu and check whether it must be migrated to another cpu.
xen/common/domain.c +2 -2
@@ -734,7 +734,7 @@ void vcpu_unpause(struct vcpu *v)void vcpu_unpause (struct vcpu *v) {if (atomic_dec_and_test (&v->pause_count) ) -vcpu_wake (v); +vcpu_arouse (v); }void domain_pause (struct domain *d)
@@ -755,7 +755,7 @@ void domain_unpause(struct domain *d)if (atomic_dec_and_test (&d->pause_count) )for_each_vcpu ( d, v ) -vcpu_wake (v); +vcpu_arouse (v); }void domain_pause_by_systemcontroller (struct domain *d)
xen/common/schedule.c +61 -22
108 lines not on this page · raw message
xen/include/xen/sched.h +1 -0
@@ -523,6 +523,7 @@ void sched_tick_suspend(void);void sched_tick_suspend (void );void sched_tick_resume (void );void vcpu_wake (struct vcpu *d); +void vcpu_arouse (struct vcpu *d);/* like vcpu_wake, check migrate */ void vcpu_sleep_nosync (struct vcpu *d);void vcpu_sleep_sync (struct vcpu *d);
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Re: [PATCH 2 of 2] Avoid vcpu migration of paused vcpus
Your original patch didn't touch this code. Was that an omission in the original version? On reflection I prefer your original patch to this new approach. I'll apply it if you still believe your original patch is complete and correct as it stands.
-- Keir
Quoted 25 lines · Juergen Gross
Currently offlining a cpu will migrate all vcpus which were active on that cpu to another one, possibly breaking existing cpu affinities.
In case of an ACPI state change the cpus are taken offline and online later (if not poweroff) while all domains are paused. There is no reason to migrate the vcpus during offlining the cpus, as the cpus will be available again when the domains are being unpaused.
This patch defers the migration check in case of paused vcpus or domains by adding
vcpu_arouse()to wake up a vcpu and check whether it must be migrated to another cpu.Signed-off-by Juergen Gross <[email protected]>3 files changed, 64 insertions(+), 24 deletions(-) xen/common/domain.c | 4 +- xen/common/schedule.c | 83 ++++++++++++++++++++++++++++++++++------------- xen/include/xen/sched.h | 1_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Re: [PATCH 2 of 2] Avoid vcpu migration of paused vcpus
Quoted 4 lines · Keir Fraser
Your original patch didn't touch this code. Was that an omission in the original version? On reflection I prefer your original patch to this new approach. I'll apply it if you still believe your original patch is complete and correct as it stands.
I like my second patch more :-)
It covers more cases, not just poweroff. In hibernate case no vcpu pinnings will be lost. Today all vcpus pinned to a cpu other than 0 will lose their pinnings at cpu offlining. At reactivation those pinnings will not be restored automatically. My patch will cover that by checking availability of the cpus after reactivation.
Poweroff (which was my primary concern) works with both versions. I did not test other ACPI state changes with either version, but would expect better results in hibernate case with my second approach.
Juergen
Quoted 37 lines
-- Keir
Quoted 21 lines · Juergen Gross
Currently offlining a cpu will migrate all vcpus which were active on that cpu to another one, possibly breaking existing cpu affinities.
In case of an ACPI state change the cpus are taken offline and online later (if not poweroff) while all domains are paused. There is no reason to migrate the vcpus during offlining the cpus, as the cpus will be available again when the domains are being unpaused.
This patch defers the migration check in case of paused vcpus or domains by adding
vcpu_arouse()to wake up a vcpu and check whether it must be migrated to another cpu.Signed-off-by Juergen Gross<[email protected]>3 files changed, 64 insertions(+), 24 deletions(-) xen/common/domain.c | 4 +- xen/common/schedule.c | 83 ++++++++++++++++++++++++++++++++++------------- xen/include/xen/sched.h | 1Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Signature · 5 lines
Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: [email protected] Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
Re: [PATCH 2 of 2] Avoid vcpu migration of paused vcpus
Quoted 14 lines · Juergen Gross
Quoted 4 lines · Keir Fraser
Your original patch didn't touch this code. Was that an omission in the original version? On reflection I prefer your original patch to this new approach. I'll apply it if you still believe your original patch is complete and correct as it stands.
I like my second patch more :-)
It covers more cases, not just poweroff. In hibernate case no vcpu pinnings will be lost. Today all vcpus pinned to a cpu other than 0 will lose their pinnings at cpu offlining. At reactivation those pinnings will not be restored automatically. My patch will cover that by checking availability of the cpus after reactivation.
Quoted 3 lines
Poweroff (which was my primary concern) works with both versions. I did not test other ACPI state changes with either version, but would expect better results in hibernate case with my second approach.
How about the attached patch? Which is similar to your original patch except I added the global state variable, and I added a check for it to cpu_disable_scheduler(). It's nice and small. :-)
-- Keir
Quoted 42 lines
Juergen
Quoted 38 lines
-- Keir
Quoted 22 lines · Juergen Gross
Currently offlining a cpu will migrate all vcpus which were active on that cpu to another one, possibly breaking existing cpu affinities.
In case of an ACPI state change the cpus are taken offline and online later (if not poweroff) while all domains are paused. There is no reason to migrate the vcpus during offlining the cpus, as the cpus will be available again when the domains are being unpaused.
This patch defers the migration check in case of paused vcpus or domains by adding
vcpu_arouse()to wake up a vcpu and check whether it must be migrated to another cpu.Signed-off-by Juergen Gross<[email protected]>3 files changed, 64 insertions(+), 24 deletions(-)
xen/common/domain.c| 4 +-xen/common/schedule.c| 83
++++++++++++++++++++++++++++++++++-------------xen/include/xen/sched.h| 1Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Juergen Gross
Acked-byRe: [PATCH 2 of 2] Avoid vcpu migration of paused vcpus
Quoted 15 lines · Keir Fraser
Quoted 13 lines · Juergen Gross
Quoted 4 lines · Keir Fraser
Your original patch didn't touch this code. Was that an omission in the original version? On reflection I prefer your original patch to this new approach. I'll apply it if you still believe your original patch is complete and correct as it stands.
I like my second patch more :-)
It covers more cases, not just poweroff. In hibernate case no vcpu pinnings will be lost. Today all vcpus pinned to a cpu other than 0 will lose their pinnings at cpu offlining. At reactivation those pinnings will not be restored automatically. My patch will cover that by checking availability of the cpus after reactivation.
Quoted 6 lines
Quoted 3 lines
Poweroff (which was my primary concern) works with both versions. I did not test other ACPI state changes with either version, but would expect better results in hibernate case with my second approach.
How about the attached patch? Which is similar to your original patch except I added the global state variable, and I added a check for it to
cpu_disable_scheduler(). It's nice and small. :-)
And it works in all of my test cases for poweroff. :-)
Thanks, Juergen
Quoted 47 lines
-- Keir
Quoted 39 lines
Juergen
Quoted 37 lines
-- KeirQuoted 22 lines · Juergen Gross
Currently offlining a cpu will migrate all vcpus which were active on that cpu to another one, possibly breaking existing cpu affinities.
In case of an ACPI state change the cpus are taken offline and online later (if not poweroff) while all domains are paused. There is no reason to migrate the vcpus during offlining the cpus, as the cpus will be available again when the domains are being unpaused.
This patch defers the migration check in case of paused vcpus or domains by adding
vcpu_arouse()to wake up a vcpu and check whether it must be migrated to another cpu.Signed-off-by Juergen Gross<[email protected]>3 files changed, 64 insertions(+), 24 deletions(-)
xen/common/domain.c| 4 +-xen/common/schedule.c| 83
++++++++++++++++++++++++++++++++++-------------xen/include/xen/sched.h| 1Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Signature · 5 lines
Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: [email protected] Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Re: [PATCH 2 of 2] Avoid vcpu migration of paused vcpus
In reply to Keir FraserQuoted 15 lines · Keir Fraser
Quoted 13 lines · Juergen Gross
Quoted 4 lines · Keir Fraser
Your original patch didn't touch this code. Was that an omission in the original version? On reflection I prefer your original patch to this new approach. I'll apply it if you still believe your original patch is complete and correct as it stands.
I like my second patch more :-)
It covers more cases, not just poweroff. In hibernate case no vcpu pinnings will be lost. Today all vcpus pinned to a cpu other than 0 will lose their pinnings at cpu offlining. At reactivation those pinnings will not be restored automatically. My patch will cover that by checking availability of the cpus after reactivation.
Quoted 6 lines
Quoted 3 lines
Poweroff (which was my primary concern) works with both versions. I did not test other ACPI state changes with either version, but would expect better results in hibernate case with my second approach.
How about the attached patch? Which is similar to your original patch except I added the global state variable, and I added a check for it to
cpu_disable_scheduler(). It's nice and small. :-)
Would you mind putting it in 4.1, too?
Juergen
Signature · 5 lines
Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: [email protected] Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
Re: [PATCH 2 of 2] Avoid vcpu migration of paused vcpus
In reply to Juergen GrossQuoted 5 lines
Quoted 1 line
Quoted 1 line · Juergen Gross
xen/common/schedule.c +0
-0@@ -525,6 +525,47 @@ void vcpu_force_reschedule(struct vcpu * }
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu * · line 535
Quoted 10 lines
xen/common/schedule.c +8
-0} +static int vcpu_chk_affinity (struct vcpu *v,unsigned int cpu) +{ +cpumask_t online_affinity; +struct cpupool *c; + + c = v->domain->cpupool; +cpumask_and (&online_affinity, v->cpu_affinity, c->cpu_valid); + if ( cpumask_empty(&online_affinity) &&
There's no need for a local cpumask_t variable here - please use !cpumask_intersects(v->cpu_affinity, c->cpu_valid) instead.
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu * · line 543
Quoted 8 lines
xen/common/schedule.c +8
-0+ cpumask_test_cpu(cpu, v->cpu_affinity) ) + { +printk ("Breaking vcpu affinity for domain %d vcpu %d\n" , + v->domain->domain_id, v->vcpu_id); +cpumask_setall (v->cpu_affinity); + } + +return ( !cpumask_test_cpu (cpu, c->cpu_valid) && (v->processor == cpu) );
Please drop the extra outermost parentheses.
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu * · line 551
Quoted 8 lines
xen/common/schedule.c +8
-0+} + +void vcpu_arouse (struct vcpu *v) +{ +unsigned long flags; + +if (atomic_read (&v->pause_count) || +atomic_read (&v->domain->pause_count) )
Is it not possible (or even more correct) to use vcpu_runnable() here?
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu * · line 556
Quoted 5 lines
xen/common/schedule.c +5
-0+return ; + +vcpu_schedule_lock_irqsave (v, flags); + +if (unlikely (vcpu_chk_affinity (v, v->processor) && (v != current)) )
unlikely() is generally useful only around individual conditions (i.e. not around && or || expressions).
Quoted 24 lines
xen/common/schedule.c +12
-1+ { +set_bit (_VPF_migrating, &v->pause_flags); +vcpu_schedule_unlock_irqrestore (v, flags); +vcpu_migrate (v); +return ; + } + +vcpu_schedule_unlock_irqrestore (v, flags); + +vcpu_wake (v); +} +/* * This function is used by cpu_hotplug code from stop_machine context * and from cpupools to switch schedulers on a cpu. @@ -534,7 +575,6 @@ int cpu_disable_scheduler(unsigned int cstruct domain *d;struct vcpu *v;struct cpupool *c; -cpumask_t online_affinity;int ret =0 ; c =per_cpu (cpupool, cpu);
xen/common/schedule.c int cpu_disable_scheduler(unsigned int c · line 591
Quoted 8 lines
xen/common/schedule.c +2
-3@@ -547,34 +587,33 @@ int cpu_disable_scheduler(unsigned int c {vcpu_schedule_lock_irq (v); -cpumask_and (&online_affinity, v->cpu_affinity, c->cpu_valid); -if (cpumask_empty (&online_affinity) && -cpumask_test_cpu (cpu, v->cpu_affinity) ) +if (likely (!atomic_read (&v->pause_count) && + !atomic_read (&d->pause_count)) )
Same question as above regarding vcpu_runnable().
Quoted 6 lines
xen/common/schedule.c +1
-4{ -printk ("Breaking vcpu affinity for domain %d vcpu %d\n" , - v->domain->domain_id, v->vcpu_id); -cpumask_setall (v->cpu_affinity); - } +if (vcpu_chk_affinity (v, cpu) )
xen/common/schedule.c int cpu_disable_scheduler(unsigned int c · line 603
Quoted 10 lines
xen/common/schedule.c +10
-0+ { +set_bit (_VPF_migrating, &v->pause_flags); +vcpu_schedule_unlock_irq (v); +vcpu_sleep_nosync (v); +vcpu_migrate (v); + } + else + { +vcpu_schedule_unlock_irq (v); + }
Please drop the unnecessary braces here, as per the recently posted coding style draft.
Jan
Quoted 30 lines
xen/common/schedule.c +7
-14-if ( v->processor == cpu ) - { -set_bit (_VPF_migrating, &v->pause_flags); -vcpu_schedule_unlock_irq (v); -vcpu_sleep_nosync (v); -vcpu_migrate (v); +/* +* A vcpu active in the hypervisor will not be migratable. +* The caller should try again after releasing and reaquiring +* all locks. +*/ +if ( v->processor == cpu ) + ret = -EAGAIN ; }else {vcpu_schedule_unlock_irq (v); } - -/* -* A vcpu active in the hypervisor will not be migratable. -* The caller should try again after releasing and reaquiring -* all locks. -*/ -if ( v->processor == cpu ) - ret = -EAGAIN ; }domain_update_node_affinity (d);
Re: [PATCH 2 of 2] Avoid vcpu migration of paused vcpus
Quoted 7 lines · Jan Beulich
Quoted 7 lines
Quoted 1 line
Quoted 1 line · Juergen Gross
xen/common/schedule.c +0
-0@@ -525,6 +525,47 @@ void vcpu_force_reschedule(struct vcpu * } }
Quoted 10 lines
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu *
Quoted 8 lines
xen/common/schedule.c +8
-0+static int vcpu_chk_affinity (struct vcpu *v,unsigned int cpu) +{ +cpumask_t online_affinity; +struct cpupool *c; + + c = v->domain->cpupool; +cpumask_and (&online_affinity, v->cpu_affinity, c->cpu_valid); + if ( cpumask_empty(&online_affinity)&&There's no need for a local
cpumask_tvariable here - please use !cpumask_intersects(v->cpu_affinity,c->cpu_valid) instead.
Okay.
Quoted 9 lines
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu *
Quoted 8 lines
xen/common/schedule.c +8
-0+ cpumask_test_cpu(cpu, v->cpu_affinity) ) + { +printk ("Breaking vcpu affinity for domain %d vcpu %d\n" , + v->domain->domain_id, v->vcpu_id); +cpumask_setall (v->cpu_affinity); + } + +return ( !cpumask_test_cpu (cpu, c->cpu_valid)&& (v->processor == cpu) );Please drop the extra outermost parentheses.
Okay.
Quoted 9 lines
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu * · line 551
Quoted 8 lines
xen/common/schedule.c +8
-0+} + +void vcpu_arouse (struct vcpu *v) +{ +unsigned long flags; + +if (atomic_read (&v->pause_count) || +atomic_read (&v->domain->pause_count) )Is it not possible (or even more correct) to use
vcpu_runnable()here?
No. There might be flags set in v->pause_flags which I don't want to test here. I'm only interested in "real" paused state. An old "migrating" case should be reconsidered here, e.g.
Quoted 7 lines
xen/common/schedule.c void vcpu_force_reschedule(struct vcpu *
Quoted 5 lines
xen/common/schedule.c +5
-0+return ; + +vcpu_schedule_lock_irqsave (v, flags); + +if (unlikely (vcpu_chk_affinity (v, v->processor)&& (v != current)) )
unlikely()is generally useful only around individual conditions (i.e. not around&& or || expressions).
Ah, I didn't know that. Will change it.
Quoted 27 lines
Quoted 27 lines
xen/common/schedule.c +12
-1+ { +set_bit (_VPF_migrating,&v->pause_flags); +vcpu_schedule_unlock_irqrestore (v, flags); +vcpu_migrate (v); +return ; + } + +vcpu_schedule_unlock_irqrestore (v, flags); + +vcpu_wake (v); +} +/* * This function is used by cpu_hotplug code from stop_machine context * and from cpupools to switch schedulers on a cpu. @@ -534,7 +575,6 @@ int cpu_disable_scheduler(unsigned int cstruct domain *d;struct vcpu *v;struct cpupool *c; -cpumask_t online_affinity;int ret =0 ; c =per_cpu (cpupool, cpu);@@ -547,34 +587,33 @@ int cpu_disable_scheduler(unsigned int c {vcpu_schedule_lock_irq (v);
Quoted 6 lines
xen/common/schedule.c int cpu_disable_scheduler(unsigned int c · line 591
Quoted 5 lines
xen/common/schedule.c +2
-3-cpumask_and (&online_affinity, v->cpu_affinity, c->cpu_valid); -if (cpumask_empty (&online_affinity)&& -cpumask_test_cpu (cpu, v->cpu_affinity) ) +if (likely (!atomic_read (&v->pause_count)&& + !atomic_read (&d->pause_count)) )Same question as above regarding
vcpu_runnable().
Same answer :-)
Quoted 16 lines
Quoted 6 lines
xen/common/schedule.c +1
-4{ -printk ("Breaking vcpu affinity for domain %d vcpu %d\n" , - v->domain->domain_id, v->vcpu_id); -cpumask_setall (v->cpu_affinity); - } +if (vcpu_chk_affinity (v, cpu) )xen/common/schedule.c int cpu_disable_scheduler(unsigned int c · line 603
Quoted 10 lines
xen/common/schedule.c +10
-0+ { +set_bit (_VPF_migrating,&v->pause_flags); +vcpu_schedule_unlock_irq (v); +vcpu_sleep_nosync (v); +vcpu_migrate (v); + } + else + { +vcpu_schedule_unlock_irq (v); + }
Quoted 2 lines
Please drop the unnecessary braces here, as per the recently posted coding style draft.
Okay.
Juergen
Signature · 5 lines
Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: [email protected] Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html