From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCHv3 1/3] rdmacg: Added rdma cgroup controller. Date: Fri, 12 Feb 2016 11:45:21 -0500 Message-ID: <20160212164521.GH3741@mtj.duckdns.org> References: <20160130183015.GP32380@htj.duckdns.org> <20160131100237.GS32380@htj.duckdns.org> <20160131110420.GV32380@htj.duckdns.org> <20160201184046.GD14091@mtj.duckdns.org> <56BB6502.8040507@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Parav Pandit Cc: Haggai Eran , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, lizefan@huawei.com, Johannes Weiner , Doug Ledford , Liran Liss , "Hefty, Sean" , Jason Gunthorpe , Jonathan Corbet , james.l.morris@oracle.com, serge@hallyn.com, Or Gerlitz , Matan Barak , raindel@mellanox.com, akpm@linux-foundation.org, linux-security-module@vger.kernel.org List-Id: linux-rdma@vger.kernel.org Hello, Parav. On Fri, Feb 12, 2016 at 02:49:38AM +0530, Parav Pandit wrote: > 1. Removed two type of resource pool, made is single type (as you > described in past comment) > 2. Removed match tokens and have array definition like "qp", "mr", "cq" etc. > 3. Wrote small parser and avoided match_token API as that won't work > due to different array definition > 4. Removed one-off remove API to unconfigure cgroup, instead all > resource should be set to max. > 5. Removed resource pool type (user/default), instead having max_num_cnt, > when ref_cnt drops to zero and max_num_cnt = total_rescource_cnt, pool is freed. > 6. Resource definition ownership is now only with IB stack at single > header file, no longer in each low level driver. > This goes through IB maintainer and other reviewers eyes. > This continue to give flexibility to not force kernel upgrade for few > enums additions for new resource type. > 7. Wherever possible pool lock is pushed out, except for hierarchical > charging/unchanging points, as it not possible to do so, due to > iterative process involves blocking allocations of rpool. Coming up > more levels up to release locks doesn't make any sense either. > This is anyway slow path where rpool is not allocated. Except for > typical first resource allocation, this is less traveled path. > 8.Other minor cleanups. > 9. Avoided %d manipulation due to removal of match_token and replaced > with seq_putc etc friend functions. Sounds great. Can't tell too much without looking at the code tho. Thanks. -- tejun