search for: schedule_data

================== STATUS ================== I do the heavy load test of create/destroy. CREDIT scheduler(cshed_schedule) checks BUG_ON(!vcpu_running) at the end of code. It makes error. The reason is that atomic_inc(&v->pausecnt)@vcpu_pause() is called without lock. (spin_lock(&schedule_data[cpu].schedule_lock)) This lock-less "pausecnt" makes vcpu_running state changing during the lock of spin_lock_irq(&schedule_data[cpu].schedule_lock)@__enter_schduler(). The code of cshed_schedule exists within this lock. =================== REPRODUCE THE ERROR ===================...

...05:36.000000000 +0200 +++ 2009-07-10/xen/common/schedule.c 2009-07-15 10:03:11.000000000 +0200 @@ -918,7 +918,7 @@ void __init scheduler_init(void) open_softirq(SCHEDULE_SOFTIRQ, schedule); - for_each_cpu ( i ) + for_each_possible_cpu ( i ) { spin_lock_init(&per_cpu(schedule_data, i).schedule_lock); init_timer(&per_cpu(schedule_data, i).s_timer, s_timer_fn, NULL, i); --- 2009-07-10.orig/xen/common/timer.c 2009-02-18 17:45:17.000000000 +0100 +++ 2009-07-10/xen/common/timer.c 2009-07-15 10:02:46.000000000 +0200 @@ -529,7 +529,7 @@ void __init timer_init(void)...

I''m working on a new hypercall, do_confer, which allows the directed yielding of a vcpu to another vcpu. It is mainly used when a vcpu fails to acquire a spinlock, yielding to the lock holder instead of spinning. I ported the ppc64 spinlock implementation for the i386 linux portion. In implementing the hypercall, I''ve been trying to figure out how to get the scheduler

...f0ad1c46f10 -r 686cd624618c xen/common/schedule.c --- a/xen/common/schedule.c Thu Mar 9 16:03:23 2006 +0100 +++ b/xen/common/schedule.c Tue Mar 14 14:56:55 2006 -0600 @@ -465,7 +465,7 @@ static void __enter_scheduler(void) { update_dom_time(next); if ( next->sleep_tick != schedule_data[cpu].tick ) - send_guest_virq(next, VIRQ_TIMER); + arch_send_timer_event(next); } TRACE_4D(TRC_SCHED_SWITCH, @@ -501,7 +501,7 @@ static void t_timer_fn(void *unused) if ( !is_idle_vcpu(v) ) { update_dom_time(v); - send_guest_virq(v, VIRQ_T...

Hi,All We have tested the latest xen on VT platform with Intel 915/E8500 chipset. Two platforms (PAE/32E) test all are based on SMP, It means that we boot up SMP guest OS in VMX. Here is the test summary: New issue (1) ================================================ 1) Fails to restore VMX guests http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=929 Issues List (3):

Address some credit2 issues. This patch series, along with the recent changes to the cpupools interface, should address some of the strange credit2 instability. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...an 16 14:17:36 2007 -0800 @@ -30,6 +30,7 @@ #include <xen/mm.h> #include <xen/errno.h> #include <xen/guest_access.h> +#include <xen/rcupdate.h> #include <xen/multicall.h> #include <public/sched.h> @@ -552,9 +553,15 @@ static void schedule(void) struct schedule_data *sd; struct task_slice next_slice; s32 r_time; /* time for new dom to run */ + int cpu = smp_processor_id(); ASSERT(!in_irq()); ASSERT(this_cpu(mc_state).flags == 0); + + if (rcu_pending(cpu)) + /* since __enter_schedule...

...an 16 14:17:36 2007 -0800 @@ -30,6 +30,7 @@ #include <xen/mm.h> #include <xen/errno.h> #include <xen/guest_access.h> +#include <xen/rcupdate.h> #include <xen/multicall.h> #include <public/sched.h> @@ -552,9 +553,15 @@ static void schedule(void) struct schedule_data *sd; struct task_slice next_slice; s32 r_time; /* time for new dom to run */ + int cpu = smp_processor_id(); ASSERT(!in_irq()); ASSERT(this_cpu(mc_state).flags == 0); + + if (rcu_pending(cpu)) + /* since __enter_schedule...

Hello, This small series deals with some weirdness in the mechanism with which the credit scheduler choses what PCPU to tickle upon a VCPU wake-up. Details are available in the changelog of the first patch. The new approach has been extensively benchmarked and proved itself either beneficial or harmless. That means it does not introduce any significant amount of overhead and/or performances

...ler!*/ + /* Check whether the awakened task needs to invoke the do_schedule + * routine. Try to avoid unnecessary runs but: + * Save approximation: Always switch to scheduler! + */ ASSERT(d->processor >= 0); ASSERT(d->processor < nr_cpu_ids); ASSERT(per_cpu(schedule_data, d->processor).curr); @@ -1244,7 +1169,7 @@ static void sedf_dump_domain(struct vcpu } -/* dumps all domains on the specified cpu */ +/* Dumps all domains on the specified cpu */ static void sedf_dump_cpu_state(const struct scheduler *ops, int i) { struct list_head *list, *queue,...