On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote:
> On 12/08/16 05:07, Dario Faggioli wrote:
> Let me know if you want me to check this in as-is or if you think you
> might send a follow-up patch adding an ASSERT.
>
Done, and it actually explodes like this:
(XEN) [4.870128] Xen call tr
On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote:
> On 12/08/16 05:07, Dario Faggioli wrote:
> >
> > Reported-by: Andrew Cooper
> > Signed-off-by: Dario Faggioli
> It might be nice if we could add an ASSERT() that the appropriate
> runqueue was locked, to make sure we don't get caught out
On 12/08/16 05:07, Dario Faggioli wrote:
> In the Credit1 hunk of 9f358ddd69463 ("xen: Have
> schedulers revise initial placement") csched_cpu_pick()
> is called without taking the runqueue lock of the
> (temporary) pCPU that the vCPU has been assigned to
> (e.g., in XEN_DOMCTL_max_vcpus).
>
> How
In the Credit1 hunk of 9f358ddd69463 ("xen: Have
schedulers revise initial placement") csched_cpu_pick()
is called without taking the runqueue lock of the
(temporary) pCPU that the vCPU has been assigned to
(e.g., in XEN_DOMCTL_max_vcpus).
However, although 'hidden' in the IS_RUNQ_IDLE() macro,
th
