[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG53R5VsFW+h9gU0SgidPwS7nQbyiMdShqNopbFX0=MwaFAYFw@mail.gmail.com>
Date: Wed, 16 Sep 2015 10:11:01 +0530
From: Parav Pandit <pandit.parav@...il.com>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc: "Hefty, Sean" <sean.hefty@...el.com>, Tejun Heo <tj@...nel.org>,
Doug Ledford <dledford@...hat.com>,
"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"lizefan@...wei.com" <lizefan@...wei.com>,
Johannes Weiner <hannes@...xchg.org>,
Jonathan Corbet <corbet@....net>,
"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
"serge@...lyn.com" <serge@...lyn.com>,
Haggai Eran <haggaie@...lanox.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Matan Barak <matanb@...lanox.com>,
"raindel@...lanox.com" <raindel@...lanox.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource
Hi Jason, Sean, Tejun,
I am in process of defining new approach, design based on the feedback
given here for new RDMA cgroup from all of you.
I have also collected feedback from Liran yesterday and ORNL folks too.
Soon I will post the new approach, high level APIs and functionality
for review before submitting actual implementation.
Regards,
Parav Pandit
On Tue, Sep 15, 2015 at 9:15 AM, Jason Gunthorpe
<jgunthorpe@...idianresearch.com> wrote:
> On Tue, Sep 15, 2015 at 08:38:54AM +0530, Parav Pandit wrote:
>
>> As you precisely described, about wild ratio,
>> we are asking vendor driver (bottom most layer) to statically define
>> what the resource pool is, without telling him which application are
>> we going to run to use those pool.
>> Therefore vendor layer cannot ever define "right" resource pool.
>
> No, I'm saying the resource pool is *well defined* and *fixed* by each
> hardware.
>
> The only question is how do we expose the N resource limits, the list
> of which is totally vendor specific.
>
>> rdma cgroup will allow us to run post 512 or 1024 containers without
>> using PCIe SR-IOV, without creating any vendor specific resource
>> pools.
>
> If you ignore any vendor specific resource limits then you've just
> left open a hole, a wayward container can exhaust all others - so what
> was the point of doing all this work?
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists