Hi Tejun, On Mon, Oct 10, 2016 at 5:55 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, Parav. > > On Mon, Oct 10, 2016 at 11:59:45AM +0530, Parav Pandit wrote: >> >> Weight can be in range of 1 to 10,000 similar to cpu cgroup. >> > >> > This is exactly what I don't like, the percentage will remove from the >> > user the translation needs between weight and actual limitation. >> > >> > IMHO CPU used weights because everything there is in weights :). >> >> I admit weight are not very intuitive, I was aligning to the existing >> other cgroup interfaces which achieves similar functionality. >> I will let Tejun approve the "percentage" or "ratio" new file >> interface as its little different than weight. > > So, if there is gonna be a proportional control mechanism, it should > use the same interface convention as other proportional controls. Thats what I was suggesting to Leon. > Also, I don't get what you mean by using percentage and when people > brought up this idea, it always has been stemming from > misunderstanding. Can you please elaborate how percentage based > proportional control would work? What would 100% mean when cgroups > can come and go? When 100% is given to one cgroup, all resources of all type can be charged by processes of that cgroup. Resources are stateful resource. So when cgroup goes away, they go back to global pool (or hw). Giving 100% to two cgroups is configuration error anyway (or without config). > > If you're suggesting expressing absolute limits in terms of > percentage, that is not proportional control. That's just using a > different unit for absolute resource limits and it must not be called > weight. > >> weight or percentage helps in abstracting as starting point. So I like >> to add it too. > > Way back, when rdmacg was proposed first, I asked the same question - > whether there can be a higher level abstraction for rdma resources, > and, IIRC, the collective answer was that the there can be no > universal measure of resources in the kernel because a large part of > resource management actually takes place in userspace. > Yes. This still holds true. I don't think anything changed. proportional knob by kernel provides constrained know of equally distribute all type of resources. This works only on one class of application. Thats the primary reason we had knob for verb level well defined resource. (Which is subset of what patchv12 had to offer, where such configuration can be done by the user space). What is not part of patchv12 is - currently max limit is configured as "max", instead of real max value. Due to which user space tool is unable to configure exact value to program to achieve functionality of ratio. This new functionality can be done post this patch as this is incremental functionality for user space tools. As you know weight configuration allows automatic increase/decrease of resource to other cgroups when one of them go away, as opposed to absolute value. How this is going to work in exact terms for stateful resource, we don't know yet. I haven't though through the design either from kernel side. So just started exploring if weight interface can be leveraged. > If I misunderstood, please correct me but what's being suggested here > seems to be implementing the knob in rdamcg and letting the specific > drivers worry about the actual resource provisioning and even then > there doesn't seem to be a clear way of semantically defining what > ratios would mean. Nop. Thats not true. (a) Every new resource has to be defined in cgroup_rdma.h (b) charge()/uncharge() has to happen by the cgroup for each. (c) Letting drivers do will make things fall apart. There are no APIs exposed either to let drivers know process cgroup either. There is no intention either. (d) ratio means -if adapter has 100 resources of type - A, 80 resource of type - B, 10% for cgroup-1 means, 10 resource of type - A 8 resource of type - B > > Let's please first establish what the resource control would exactly > mean. > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
