Quoting Wang, Zhi A (2017-09-26 07:20:00) > Thanks for the explanation 2). :) > > I'm thinking about the rough design of preemption in GVT-g since host is moving to support preemption. > > 1) Global MMIO save/restore, which is covered by context status notifier. > > 2) Support host preemption. GVT-g request is preempted by host. Since this preemption is not expected by guest, GVT-g workload scheduler should keep it and re-schedule it. > > * GVT-g has to know if a context is scheduled-out or preempted here, it's better the context notification can explicitly report INTEL_CONTEXT_PREEMPTED. Or we have to get the information from context or request data structure. > * Better the re-scheduling of GVT-g request can be controlled by GVT-g not i915, since GVT-g has its own scheduling policies. You'll get the sequence CONTEXT_IN, CONTEXT_PREEMPTED, CONTEXT_IN..., CONTEXT_OUT Happy? But it feels like we should be focusing on a single scheduler, rather than in the end having two timeslicing CFS (and the different modes). It's para-virt vs full-virt, and I thought gvt-g was more about being a lightweight para-virt... > 3) Guest preemption. Guest requests a preemption by writing vELSP. GVT-g has to find a way to stop the previous GVT-g request if it's active on HW. If it's not active on HW, the request should be cancelled. > > * If host can expose such a APIs to cancel request in HW(by preemption) or in priotree for GVT-g , that would be nice. :) Hmm, the interface exists for the purpose of native requests. Rough approach would be to use a second gvt context that preempts the first, then when you know that's been scheduled, you can then requeue the normal gvt context. But I'd rather we get to the point where we all feed into the same scheduler, rather than having callbacks from within it. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
