On Tue, Dec 11, 2012 at 06:27:42AM -0800, Tejun Heo wrote: > On Tue, Dec 11, 2012 at 09:25:18AM -0500, Vivek Goyal wrote: > > In general, do not use blkcg on faster storage. In current form it > > is at best suitable for single rotational SATA/SAS disk. I have not > > been able to figure out how to provide fairness without group idling. > > I think cfq is just the wrong approach for faster non-rotational > devices. We should be allocating iops instead of time slices. 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. 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. 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. Thanks Vivek _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
