Hello, On Thu, Jan 07, 2016 at 05:03:07AM +0530, Parav Pandit wrote: > Rdma resource can be allocated by parent process, used and freed by > child process. > Child process could belong to different rdma cgroup. > Parent process might have been terminated after creation of rdma > cgroup. (Followed by cgroup might have been deleted too). > Its discussed in https://lkml.org/lkml/2015/11/2/307 > > In nutshell, there is process that clearly owns the rdma resource. > So to keep the design simple, rdma resource is owned by the creator > process and cgroup without modifying the task_struct. So, a resource created by a task in a cgroup staying in the cgroup when the task gets migrated is fine; however, a resource being allocated in a previous cgroup of the task isn't fine. Once allocated, the resource themselves should be associated with the cgroup so that they can be freed from the ones they're allocated from. If I'm understanding it correctly, the code is bending basic rules around how resource and task cgroup membership is tracked, you really can't do that. > > I'm pretty sure you can get away with an fixed length array of > > counters. Please keep it simple. It's a simple hard limit enforcer. > > There's no need to create a massive dynamic infrastrucure. > > Every resource pool for verbs resource is fixed length array. Length > of the array is defined by the IB stack modules. > This array is per cgroup, per device. > Its per device, because we agreed that we want to address requirement > of controlling/configuring them on per device basis. > Devices appear and disappear. Therefore they are allocated dynamically. > Otherwise this array could be static in cgroup structure. Please see the previous response. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
