Hi Tejun, Thank you very much for the reply. We will try to explore some alternatives at application side for this purpose. Thanks, Guang On Tue, Apr 18, 2017 at 12:15 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Tue, Apr 04, 2017 at 10:54:41AM -0700, Guang Yang wrote: >> I am experimenting the IO throttling with cgroups, with some good >> reading from online and experiments, I found that we have two options: >> 1. with CFQ IO scheduler, we can set a percentage of serving time one >> group can take, and if one group does not fully take its share, other >> (busy) group can steal the shares from the (ideal) group. >> 2. with deadline IO scheduler, we can set an absolute IOPS and >> bandwidth for one group, however, this does not consider the cost of >> serving the IO (e.g. sequential vs. random) and thus it is hard to >> give fair share between groups. > > Yeah, that's correct. > >> Neither one seems fully fit into our requirement - we hope that cost >> model is based on the serving time, at the same time, we don't have >> one group be able to steal share from the other. > > I see. You want time based control which isn't work-conserving. > >> By looking online, not sure if I missed anything, I didn't see a way >> to configure cgroups IO throttling to achieve the above requirement, >> besides, if it is not supported now, is there anything on the roadmap >> to support it in the future? > > It currently isn't supported and I don't think anyone is working on > implementing something like that. For SSDs, we haven't found a way to > estimate the "serving time" in a scalable manner, so the outlook for > the time based scheduling / control doesn't look too bright. > > It's a lot more cumbersome to configure but in a lot of cases limiting > both bandwidth and IOPS can be good enough in limiting usage to some > proportion across different workloads. > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
