Hi Tejun, On Thu, Oct 20, 2016 at 12:50 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Thu, Oct 20, 2016 at 12:33:53AM +0530, Parav Pandit wrote: >> > or config changes in one of the ancestors? What "max" means is "no >> > limit is imposed" which is different from "limit it to 100% of what's >> > currently available". >> >> Charging is hierarchical for rdmacg too. >> rdma.max configuration exist at all the levels so ancestors change >> won't affect its children. >> rdma.max absolute (or future percentage) value is with reference to >> the total device resources. > > Ah, right, the percentage is out of the total device resources > regardless of the hierarchical restrictions. I still don't think it's > a good idea for rdmacg to deviate from the common interface > conventions. If you want to do the percentage calculation in the > userland and the base numbers are system-wide numbers which are > hardware dependent, it'd be best if there's an existing place where > the numbers can be exposed naturally. That'd be more in line with > others too. The amount of total resources available for the device > isn't tied to cgroup after all. > userland can get the max numbers using other framework which is used by control & data plane available in C library form or in form of system tools. I was preferring to get and set through same interface because, It simplifies user land software which is often not written in C so its likely that it needs to rely on system tools and parse the content, iterate through devices etc. Getting these info through rdma.max just makes it simple. There will be logic built to read/write rdma.max in userland anyway, which can be leveraged for percentage calculation instead of doing it from two places. > 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
