[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC V2 42/45] xen/sched: add fall back to idle vcpu when scheduling item
>>> On 06.05.19 at 08:56, <jgross@xxxxxxxx> wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -154,6 +154,24 @@ static void idle_loop(void) > } > } > > +/* > + * Idle loop for siblings of active schedule items. > + * We don't do any standard idle work like tasklets, page scrubbing or > + * livepatching. > + * Use default_idle() in order to simulate v->is_urgent. I guess I'm missing a part of the description which explains all this: What's wrong with doing scrubbing work, for example? Why is doing tasklet work not okay, but softirqs are? What is the deal with v->is_urgent, i.e. what justifies not entering a decent power saving mode here on Intel, but doing so on AMD? > --- a/xen/include/asm-x86/smp.h > +++ b/xen/include/asm-x86/smp.h > @@ -76,6 +76,9 @@ void set_nr_sockets(void); > /* Representing HT and core siblings in each socket. */ > extern cpumask_t **socket_cpumask; > > +#define get_cpu_current(cpu) \ > + (get_cpu_info_from_stack((unsigned long)stack_base[cpu])->current_vcpu) Yet another, slightly different notion of "current". If "current" itself is not suitable (I can't immediately see why that would be, but I also didn't look at all the scheduler specific changes earlier in this series), why isn't per_cpu(curr_vcpu, cpu) either? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |