[RFC PATCH] drm/i915/gvt: split sched_policy for adding more policies

[Zhenyu Wang]

On 2019.12.18 15:07:40 +0800, Hang Yuan wrote:
> On 12/18/19 1:43 PM, Zhenyu Wang wrote:
> > On 2019.12.18 13:07:34 +0800, Hang Yuan wrote:
> > > On 12/18/19 10:49 AM, Zhenyu Wang wrote:
> > > > On 2019.12.17 18:32:43 +0800, hang.yuan at linux.intel.com wrote:
> > > > > From: Hang Yuan <hang.yuan at linux.intel.com>
> > > > > 
> > > > > Leave common policy codes in sched_policy.c and move time based
> > > > > scheduling to new file sched_policy_weight.c. Add module parameter
> > > > > "gvt_scheduler_policy" to choose one policy.
> > > > > 
> > > > 
> > > > Before any plan to split scheduler, what's the requirement for new
> > > > policy? What's the design? Would that be integrated with default
> > > > weight for different type? Need to understand that first to decide
> > > > whether or not we have to have seperate schedulers which I'm not favor
> > > > of if can't be done by default..
> > > > 
> > > The new policy is not mature yet. Just see one user scenario where there are
> > > two vgpus, one is in foreground VM and another is in background VM. For some
> > > reason, the background VM can't be paused but end user is not using it. So
> > > its vgpu looks like not necessary to have fixed capacity as the scheduling
> > > policy right now.
> > 
> > True.
> > 
> > > Instead, want to try best to serve foreground vgpu and
> > > just avoid time out for gfx driver in background VM. Here are some rough
> > > codes based on the previous patch to schedule vgpu on priority and use a
> > > timer to increase vgpu's priority if it waits too long.
> > 
> > yeah, current method for balance is still based on fixed weight for
> > target vGPU type. I think you want fine-grained control of run
> > timeslice over vGPU's activity? or you want fixed priority? I think
> > the foreground or background could be switched, right?
> > 
> > Could we apply vGPU activity statistics in current scheduler? vGPU
> > type's weight is kind of static default allocation, we still use that
> > as base indicator for vgpu timeslice, but we'd also dynamically update
> > real execute timeslice based vgpu history. From that point of view, we
> > don't need another scheduler.
> > 
> Yes, VM can be switched between foreground and background. I think
> fine-grained control may not fit this case because the "weight" is
> determined by the switch action, not historical data.
>

Or we can have a 'nice' value to set for each vGPU from sysfs which could
be handled in current scheduler for that purpose?

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20191218/81a6905f/attachment.sig>