On 25/02/2016 16:26, Parav Pandit wrote:
>> Can we call kfree() with spin_lock held? All these years I tend to
>> avoid doing so.
> Also it doesn't look correct to hold the lock while freeing the memory
> which is totally unrelated to the lock.
> With that I think current code appears ok with excep
On 25/02/2016 15:34, Parav Pandit wrote:
> On Thu, Feb 25, 2016 at 5:33 PM, Haggai Eran wrote:
> +retry:
> + spin_lock(&cg->rpool_list_lock);
> + rpool = find_cg_rpool_locked(cg, device);
> + if (!rpool) {
> + spin_unlock(&cg->rpool_list_lock);
> +
> Can we call kfree() with spin_lock held? All these years I tend to
> avoid doing so.
Also it doesn't look correct to hold the lock while freeing the memory
which is totally unrelated to the lock.
With that I think current code appears ok with exception that its
duplicated at two place for code re
On Thu, Feb 25, 2016 at 5:33 PM, Haggai Eran wrote:
+retry:
+ spin_lock(&cg->rpool_list_lock);
+ rpool = find_cg_rpool_locked(cg, device);
+ if (!rpool) {
+ spin_unlock(&cg->rpool_list_lock);
+ ret = alloc_cg_rpool(cg, device);
On 24/02/2016 18:16, Parav Pandit wrote:
>>> + struct rdmacg_resource_pool *rpool;
>>> + struct rdmacg_pool_info *pool_info = &device->pool_info;
>>> +
>>> + spin_lock(&cg->rpool_list_lock);
>>> + rpool = find_cg_rpool_locked(cg, device);
>> Is it possible for rpool to be NULL?
>>
>
Hi,
Overall I the patch looks good to me. I have a few comments below.
On 20/02/2016 13:00, Parav Pandit wrote:
> Resource pool is created/destroyed dynamically whenever
> charging/uncharging occurs respectively and whenever user
> configuration is done. Its a tradeoff of memory vs little more co
On Wed, Feb 24, 2016 at 6:43 PM, Haggai Eran wrote:
> Hi,
>
> Overall I the patch looks good to me. I have a few comments below.
>
Thanks for the review. Addressing most comments one.
Some comments inline.
> Its -> It's
Ok.
>> +void rdmacg_query_limit(struct rdmacg_device *device,
>> +
On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote:
> Added rdma cgroup controller that does accounting, limit enforcement
> on rdma/IB verbs and hw resources.
>
> Added rdma cgroup header file which defines its APIs to perform
> charing/uncharing functionality and device registration wh
On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote:
> On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote:
> Can you place this ifdef before declaring struct rdma_cgroup?
Yes. I missed out this cleanup. Done locally now.
> Thanks
--
To unsubscribe from this list: send the line "unsub
CONFIG_CGROUP_RDMA
On Sun, Feb 21, 2016 at 7:15 PM, Leon Romanovsky wrote:
> On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote:
>> On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote:
>> > On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote:
>> > Can you place this ifdef b
On Sun, Feb 21, 2016 at 8:39 PM, Leon Romanovsky wrote:
> On Sun, Feb 21, 2016 at 07:41:08PM +0530, Parav Pandit wrote:
>> CONFIG_CGROUP_RDMA
>>
>> On Sun, Feb 21, 2016 at 7:15 PM, Leon Romanovsky wrote:
>> > On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote:
>> >> On Sun, Feb 21, 2016
On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote:
> On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote:
> > On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote:
> > Can you place this ifdef before declaring struct rdma_cgroup?
> Yes. I missed out this cleanup. Done locally
On Sun, Feb 21, 2016 at 07:41:08PM +0530, Parav Pandit wrote:
> CONFIG_CGROUP_RDMA
>
> On Sun, Feb 21, 2016 at 7:15 PM, Leon Romanovsky wrote:
> > On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote:
> >> On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote:
> >> > On Sat, Feb 20, 201
Added rdma cgroup controller that does accounting, limit enforcement
on rdma/IB verbs and hw resources.
Added rdma cgroup header file which defines its APIs to perform
charing/uncharing functionality and device registration which will
participate in controller functions of accounting and limit
enf
14 matches
Mail list logo
