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

[Hang Yuan]

On 12/18/19 4:32 PM, Zhenyu Wang wrote:
> 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?
> 
Yes, we can use sysfs to change weight in runtime for this case as well. 
Thanks for the comments.