[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v1 00/16] xen: sched: implement core-scheduling
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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |