Munehiro Ikeda wrote: ... > > Consideration and Conclusion > ============================= > > From result(1), it is observed that it takes 1000~1200[ms] to rise P2 > bandwidth. In result(2), where both of g1 and g2 have > nr_group_requests=100, the delay gets longer as 1800~2000[ms]. In > addition to it, the average bandwidth becomes ~5% lower than result(1). > This is supposed that P2 couldn't allocate enough requests. > Then, result(3) shows that bandwidth of P2 can rise quickly (~300[ms]) > if nr_group_requests can be set per-cgroup. Result(4) shows that the > delay can be shortened by setting g2 as RT class, however, the delay is > still longer than result(3). > > I think it is confirmed that "per-cgroup nr_requests limitation is > useful in a certain situation". Beyond that, the discussion topic is > the benefit pointed out above is eligible for the complication of the > implementation. IMHO, I don't think the implementation of per-cgroup > request limitation is too complicated to accept. On the other hand I > guess it suddenly gets complicated if we try to implement further more, > especially hierarchical support. It is also true that I have a feeling > that implementation without per-device limitation and hierarchical > support is like "unfinished work". > > So, my opinion so far is that, per-cgroup nr_requests limitation should > be merged only if hierarchical support is concluded "unnecessary" for > it. If merging it tempts hierarchical support, it shouldn't be. > How about your opinion, all? Hi Munehiro-san, Thanks for the great job. It seems Per-cgroup requests allocation limits has its value in some cases. IMHO, for the time being, we can just drop the hierarchical support for "Per-cgroup requests allocation limits", and see whether it can work well. > > My considerations or verification method might be wrong. Please correct > them if any. And if you have any other idea of scenario to verify the > effect of per-cgroup nr_requests limitation, please let me know. I'll > try it. > > > > > ------------------------------------------------------------------------ > -- Regards Gui Jianfeng -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
