IOPS based scheduler (Was: Re: [PATCH 18/21] blkcg: move blkio_group_conf->weight to cfq)

Tao Ma tm at tao.ma
Wed Apr 4 18:36:38 UTC 2012


On 04/05/2012 02:22 AM, Vivek Goyal wrote:
> On Thu, Apr 05, 2012 at 01:18:05AM +0800, Tao Ma wrote:
> 
> [..]
>>> I think a large chunk of that iops scheduler code will be borrowed from
>>> CFQ code. All the cgroup logic, queue creation logic, group scheduling
>>> logic etc. And that's the reason I was still exploring the possibility 
>>> of having common code base.
>> Yeah, actually I was thinking of abstracting a generic logic, but it
>> seems a lot bit hard. Maybe we can try to unify the code later?
> 
> I think if we change the cfqq scheduling logic to something similar to
> group scheduling logic, it will help a lot.
> 
> - Current virtual time based logic does not care whether you are operating
>   in time mode or iops mode. Switching cfqq logic to similar logic will
>   help moving to iops mode quickly.
> 
> - Keeping track of vtime will help that we will get rid of all the
>   residual time logic. If some queue was preempted, and did not use full
>   slice, we will automaticlally charge it less and give smaller vtime.
> 
> - Keeping both the scheduling logic will enable us the smoother
>   integration of both cfqq and group logic once we support hierarchical
>   cgroups.
> 
> - It will also enable easier integration of iops related logic.
Maybe, I will check all of these after my travel. Also I will try your
patch at that time.
> 
> So I am in favor of cleaning up CFQ code and change it to deal with both
> time as well iops. Seriously, implmenting time or iops is not hard. It is
> about rest of the logic like trees, groups which contributes towards bulk
> of the code and I am really not convinced that iops scheduler is going to
> be different enough that it needs new io scheduler.
Sure, I also want to make my problem perfect resolved while maitaining
things simple.

Thanks
Tao


More information about the Containers mailing list