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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
