Messages in this thread | | | Date | Tue, 11 Dec 2012 06:47:18 -0800 | From | Tejun Heo <> | Subject | Re: performance drop after using blkcg |
| |
Hello,
On Tue, Dec 11, 2012 at 09:43:36AM -0500, Vivek Goyal wrote: > I think if one sets slice_idle=0 and group_idle=0 in CFQ, for all practical > purposes it should become and IOPS based group scheduling.
No, I don't think it is. You can't achieve isolation without idling between group switches. We're measuring slices in terms of iops but what cfq actually schedules are still time slices, not IOs.
> For group accounting then CFQ uses number of requests from each cgroup > and uses that information to schedule groups. > > I have not been able to figure out the practical benefits of that > approach. At least not for the simple workloads I played with. This > approach will not work for simple things like trying to improve dependent > read latencies in presence of heavery writers. That's the single biggest > use case CFQ solves, IMO.
As I wrote above, it's not about accounting. It's about scheduling unit.
> And that happens because we stop writes and don't let them go to device > and device is primarily dealing with reads. If some process is doing > dependent reads and we want to improve read latencies, then either > we need to stop flow of writes or devices are good and they always > prioritize READs over WRITEs. If devices are good then we probably > don't even need blkcg. > > So yes, iops based appraoch is fine just that number of cases where you > will see any service differentiation should significantly less.
No, using iops to schedule time slices would lead to that. We just need to be allocating and scheduling iops, and I don't think we should be doing that from cfq.
Thanks.
-- tejun
| |