On Tue, Apr 03, 2012 at 06:03:03AM +0800, Tao Ma wrote: > Currently weight is just used to calculate the time slice of different > cfq group, right? So why can't it be used to indicate other weight? So > say, if we are just want to use iops to indicate the difference between > different cgroups(100 weight vs 200 weight), so one process will send > 100 ios while the other will send 200 ios just for example. Because it's configuring stuff which is completely unrelated. Let's say you added a new elevator w/ iops based proportional IO which shares blkio.weight configuration with cfq but nothing else and in turn your new thing would probably need some other config parameters which don't make much sense for cfq, right? Now, let's say there's a system which has two hard drives and sda is using cfq and sdb is using your new elevator and you're trying to configure cgroup blkio limits. Now, you have blkio.weight which applies to both elevators and other configurations which aren't and from the looks of it there's no way to tell which configuration controls what. It also makes the configuration implementation hairier. We'll need callbacks from blkcg core layer to all policies to notify changes to per-cgroup configuration and from there policies would have to decide whether it has overriding per-cgroup-device configuration. It's not even clear we even want per-cgroup configuration. blk-throttle only has per-cgroup-device configuration after all. So, again, no. blkcg.weight isn't and won't be generic. > We will need a new iops_weight in your option to be exported? Yeah, just add config and stat files prefixed with the name of the new blkcg policy. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
