[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.