Hi Liran, On Fri, Nov 4, 2016 at 10:36 AM, Liran Liss <liranl@xxxxxxxxxxxx> wrote: >> From: Parav Pandit [mailto:pandit.parav@xxxxxxxxx] > >> >> On Fri, Nov 4, 2016 at 10:22 AM, Liran Liss <liranl@xxxxxxxxxxxx> wrote: >> >> From: Parav Pandit [mailto:pandit.parav@xxxxxxxxx] >> > >> >> > >> >> > 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. >> >> >> > >> > That is the requested change. The absolute number would account for any >> object allocation. We won't distinguish between types. >> > Only a single counter (per device). >> > >> >> In that case ucontext deserve a additional count. Because that is handful in >> range of 256 to 1K. >> If we give absolute consolidated number as 2000, one container will allocate all >> the doorbell uctx and no other container can run. >> Percentage works for this particular case. >> > > Hmm.. > I guess that you are right. > > So we can add another count for "HCA handles", I prefer this. This keeps it vendor agnostic and clean if we don't go percentage route. Would indirection table also fall in this category? > or alternatively, each provider will restrict the number of handles per device to a reasonable small number (which > won't be treated as one of the "HCA resources"). This would require vendor drivers to get the understanding of cgroup object and pid and that breaks the modular approach. I like to avoid this. > Typically, a process shouldn't need to open more than a single handle... Right. well behaved application won't do multiple handles. > -- 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
