Hi Liran, On Fri, Nov 4, 2016 at 9:50 AM, Liran Liss <liranl@xxxxxxxxxxxx> wrote: >> From: Leon Romanovsky [mailto:leon@xxxxxxxxxx] > >> We (Tejun, Christoph, Matan and me) had a face-to-face talk during KS/LPC and >> decided that the best way to move forward is to export to user one object >> (global HCA like) only and don't export anything else. >> >> All internal calculations will be based on this percentage. >> >> Once the cgroups users will come with reasonable justification why they need to >> configure different unexposed objects, we will expose them. > > A global HCA metric is indeed in the right direction. > However, rethinking this, I think that we should specify the metric in terms of RDMA objects rather than percentage. > Basically, any resource that consumes an IDR is charged. > If metric definition is based on RDMA objects (count) and not based on percentage, how would user specify the metric without really specifying object type. Current patch defines the metric as absolute numbers and objects as well. Comment from Leon about his discussion with Matan, Tejun, Christoph says opposite of this for user level configuration. May be I am missing something. > The reasons are: > - Some HCAs can have a huge amount of resources (millions of objects), of which even a small percentage may consume a considerable amount of kernel memory. > - We follow the same notion as FD limits, which accounts for numerous resource types that consume file objects in the kernel (files, pipes, sockets) > - The namespaces for RDMA resources are large (usually 24 bits). So even large resource counts won't come nowhere close in depleting the namespace. (Compare that to the mere 64K socket port space...) > - The metric measures the actual application usage of resources, rather than proportional to the resources of a given HCA adapter. > - We can continue to use the cgroup mechanism for charging (just as in the original proposal) > > I have discussed this matter with Doug and Matan, and it seems like this is the right direction. > --Liran > -- 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
