Re: [PATCH 00/39] drop null test before destroy functions

> Recent commits to kernel/git/torvalds/linux.git have made the following > functions able to tolerate NULL arguments: > > kmem_cache_destroy (commit 3942d29918522) > mempool_destroy (commit 4e3ca3e033d1) > dma_pool_destroy (commit 44d7175da6ea) How do you think about to extend an other SmPL

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On Sat, Sep 12, 2015 at 1:36 AM, Hefty, Sean wrote: >> > Trying to limit the number of QPs that an app can allocate, >> > therefore, just limits how much of the address space an app can use. >> > There's no clear link between QP limits and HW resource limits, >> > unless you

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

Hi Tejun, I missed to acknowledge your point that we need both - hard limit and soft limit/weight. Current patchset is only based on hard limit. I see that weight would be another helfpul layer in chain that we can implement after this as incremental that makes review, debugging manageable?

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

Hello, Parav. On Mon, Sep 14, 2015 at 07:34:09PM +0530, Parav Pandit wrote: > I missed to acknowledge your point that we need both - hard limit and > soft limit/weight. Current patchset is only based on hard limit. > I see that weight would be another helfpul layer in chain that we can >

Re: [PATCH for-4.3] IB/ipoib: add module option for auto-creating mcast groups

On Fri, 11 Sep 2015, Doug Ledford wrote: > > At a minimum, when the socket that did the send closes the send-only > > could be de-refed.. > > If we kept a ref count, but we don't. Tracking this is not a small change. We could call ip_mc_join_group() from ipoib_mcast_send() which would join it

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On Mon, Sep 14, 2015 at 04:39:33PM +0530, Parav Pandit wrote: > 1. How does the % of resource, is different than absolute number? With > rest of the cgroups systems we define absolute number at most places > to my knowledge. There isn't really much choice if the abstraction is a bundle of all

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On Tue, Sep 15, 2015 at 12:24:41AM +0530, Parav Pandit wrote: > On Mon, Sep 14, 2015 at 10:58 PM, Jason Gunthorpe > wrote: > > On Mon, Sep 14, 2015 at 04:39:33PM +0530, Parav Pandit wrote: > > > >> 1. How does the % of resource, is different than absolute number?

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

> Because actual hardware resources *ARE* the limit. We cannot abstract > it away. The hardware/driver has real, fixed, immutable limits. No API > abstraction can possibly change that. > > The limits are such there *IS NO* API boundary that can bundle them > into something simpler. There will

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On Mon, Sep 14, 2015 at 10:58 PM, Jason Gunthorpe wrote: > On Mon, Sep 14, 2015 at 04:39:33PM +0530, Parav Pandit wrote: > >> 1. How does the % of resource, is different than absolute number? With >> rest of the cgroups systems we define absolute number at most

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On Sat, Sep 12, 2015 at 12:52 AM, Hefty, Sean wrote: >> So, the existence of resource limitations is fine. That's what we >> deal with all the time. The problem usually with this sort of >> interfaces which expose implementation details to users directly is >> that it

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On Sat, Sep 12, 2015 at 12:55 AM, Tejun Heo wrote: > Hello, Parav. > > On Fri, Sep 11, 2015 at 10:09:48PM +0530, Parav Pandit wrote: >> > If you're planning on following what the existing memcg did in this >> > area, it's unlikely to go well. Would you mind sharing what you have