Re: [RFC PATCH v1 00/16] xen: sched: implement core-scheduling

[Dario Faggioli <dfaggioli@suse.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3112 bytes --]

Hey,

Sorry if replying took some time. :-P

On Fri, 2018-09-07 at 18:00 +0200, Juergen Gross wrote:
> On 25/08/18 01:35, Dario Faggioli wrote:
> > 
> > There are git branches here:
> >  https://gitlab.com/dfaggioli/xen.git rel/sched/core-scheduling-
> > RFCv1
> >  https://github.com/fdario/xen.git rel/sched/core-scheduling-RFCv1
> > 
> > Any comment is more than welcome.
> 
> Have you thought about a more generic approach?
> 
I had. And I have thought about it more since this email. :-)

> Instead of trying to schedule only vcpus of the same domain on a core
> I'd rather switch form vcpu scheduling to real core scheduling. The
> scheduler would see guest cores to be scheduled on physical cores. A
> guest core consists of "guest threads" being vcpus (vcpus are bound
> to their guest cores, so that part of the topology could even be used
> by the guest for performance tuning). 
>
Right, so I think I got the big picture. And it was something that, as
I've said above, I've been thinking too, and we've also talked about
something similar with Andrew in Nanjing.

I'm still missing how something like this would work in details,
perhaps because I'm really used to reason within the boundaries of the
model we currently have.

So, for example:
- domain A has vCore0 and vCore1
- each vCore has 2 threads ({vCore0.0, vCore0.1} and
  {vCore1.0, vCore1.1})
- we're on a 2-way SMT host
- vCore1 is running on physical core 3 on the host
- more specifically, vCore1.0 is currently executing on thread 0 of
  physical core 3 of the host, and vCore1.1 is currently executing on
  thread 1 of core 3 of the host
- say that both vCore1.0 and vCore1.1 are in guest context

Now:
* vCore1.0 blocks. What happens?
* vCore1.0 makes an hypercall. What happens?
* vCore1.0 VMEXITs. What happens?

> The state machine determining the core state from its vcpus would be
> scheduler agnostic (schedule.c), same for switching guest cores on a
> physical core.
> 
What do you mean with "same for switching guest cores on a physical
core"?

All in all, I like the idea, because it is about introducing nice
abstractions, it is general, etc., but it looks like a major rework of
the scheduler.

And it's not that I am not up for major reworks, but I'd like to
understand properly what that is buying us.

Note that, while this series which tries to implement core-scheduling
for Credit1 is rather long and messy, doing the same (and with a
similar approach) for Credit2 is a lot easier and nicer. I have it
almost ready, and will send it soon.

> This scheme could even be expanded for socket scheduling.
> 
Right. But again, in Credit2, I've been able to implement socket-wise
coscheduling with this approach (I mean, an approach similar to the one
in this series, but adapted to Credit2).

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel