Hello, Vivek. On Thu, May 02, 2013 at 02:17:48PM -0400, Vivek Goyal wrote: > Sorry, did not understand how did you arrive at 15% penalty. I think > in worst case it will be 50%. Assume size of bio is 1MB. So it will Oh, that's the number I got by running test. > wait for 1 second in child group and then it will wait again for > another second in parent group. Assume next bio gets queued only > after first bio gets dispatched. > > That means each 1MB bio will wait for 2 second which will lead to > effective rate of .5MB/second. Then the scheduling algorithm is broken in itself regardless of hierarchy. That means an issuer which issues at exact the exactly configured pace gets penalized, right? > > I don't particularly like doing that as a separate step, maybe we can > > just push the child's start time to the parent while dispatching? > > Does that sound doable to you? > > May be. But climbing the ladder has unfairness problems too. We might > have to rethink about the hierarchical algorithm altogether. Meh, it's not different from flat case. It gives workable enough fairness from the simple fact that the queues at each layer are FIFO. Beyond that, as long as the limits are honored, it's fine. If this thing is going to be used for high-bandwidth applications, it should probably get reimplemented as per-cpu token distributing hierarchy, but blk-throttle is not gonna hold back the whole cgroup hierarchy support. If you want to reimplement the whole thing, please feel free to do so afterwards. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
