On 12/10/2018 11:15, Dario Faggioli wrote: > On Fri, 2018-10-12 at 10:35 +0200, Juergen Gross wrote: >> On 12/10/2018 09:49, Dario Faggioli wrote: >>> >>> But how easy it is to opt out, if one doesn't want it? E.g., in the >>> context of L1TF, what if I'm not affected, and hence am not >>> interested >>> in core-scheduling? What if I want a cpupool with core-scheduling >>> and >>> one without? >>> >>> I may be wrong, but out of the top of my head, but it seems to me >>> that >>> doing things in schedule.c makes this a lot harder, if possible at >>> all. >> >> Why? This would be a per-cpupool setting, so the scheduling >> granularity >> would live in struct scheduler. >> > Mmm... it's already starting to be a bit hard to reason, without > looking at at least a prototype of the code. :-/ > > But, anyway, if I'm in sched_dario.c, and schedule.c makes me reason in > terms of vCores, how do I deal with single CPUs for a particular > cpupool that does not want core-scheduling?
sched_dario.c would only know of scheduling entities. Mapping of vcpus to scheduling entities is part of the infrastructure. schedule.c would receive vcpu state changes. In case such a vcpu state change leads to a scheduling entity state change the related scheduler is informed about that to be able to react. In case the scheduling entity is a thread (no core scheduling) each vcpu state change will result in a scheduling entity state change, so it will be as today. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
