Hello,
On Tue, May 07, 2019 at 12:50:50PM -0700, Welty, Brian wrote:
> There might still be merit in having a 'device mem' cgroup controller.
> The resource model at least is then no longer mixed up with host memory.
> RDMA community seemed to have some interest in a common controller at
> least
On 5/6/2019 8:26 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
>> The patch series enables device drivers to use cgroups to control the
>> following resources within a GPU (or other accelerator device):
>> * control allocation of device memory
On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
> In containerized or virtualized environments, there is desire to have
> controls in place for resources that can be consumed by users of a GPU
> device. This RFC patch series proposes a framework for integrating
> use of existing
Hello,
On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
> The patch series enables device drivers to use cgroups to control the
> following resources within a GPU (or other accelerator device):
> * control allocation of device memory (reuse of memcg)
> and with future work, we could
Leon Romanovsky writes:
First group (programmers) is using special API [1] through libibverbs [2]
without any notion of cgroups or any limitations. Second group (sysadmins)
is less interested in application specifics and for them "device memory" means
"memory" and not "rdma, nic specific,
On Sun, May 05, 2019 at 12:34:16PM -0400, Kenny Ho wrote:
> (sent again. Not sure why my previous email was just a reply instead
> of reply-all.)
>
> On Sun, May 5, 2019 at 12:05 PM Leon Romanovsky wrote:
> > We are talking about two different access patterns for this device
> > memory (DM). One
(sent again. Not sure why my previous email was just a reply instead
of reply-all.)
On Sun, May 5, 2019 at 12:05 PM Leon Romanovsky wrote:
> We are talking about two different access patterns for this device
> memory (DM). One is to use this device memory (DM) and second to
> configure/limit.
On Sun, May 5, 2019 at 3:14 AM Leon Romanovsky wrote:
> > > Doesn't RDMA already has a separate cgroup? Why not implement it there?
> > >
> >
> > Hi Kenny, I can't answer for Leon, but I'm hopeful he agrees with rationale
> > I gave in the cover letter. Namely, to implement in rdma controller,
On Fri, May 03, 2019 at 02:14:33PM -0700, Welty, Brian wrote:
>
> On 5/2/2019 3:48 PM, Kenny Ho wrote:
> > On 5/2/2019 1:34 AM, Leon Romanovsky wrote:
> >> Count us (Mellanox) too, our RDMA devices are exposing special and
> >> limited in size device memory to the users and we would like to
On 5/2/2019 3:48 PM, Kenny Ho wrote:
> On 5/2/2019 1:34 AM, Leon Romanovsky wrote:
>> Count us (Mellanox) too, our RDMA devices are exposing special and
>> limited in size device memory to the users and we would like to provide
>> an option to use cgroup to control its exposure.
Hi Leon, great
> Count us (Mellanox) too, our RDMA devices are exposing special and
> limited in size device memory to the users and we would like to provide
> an option to use cgroup to control its exposure.
Doesn't RDMA already has a separate cgroup? Why not implement it there?
> > and with future work, we
On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
> In containerized or virtualized environments, there is desire to have
> controls in place for resources that can be consumed by users of a GPU
> device. This RFC patch series proposes a framework for integrating
> use of existing
In containerized or virtualized environments, there is desire to have
controls in place for resources that can be consumed by users of a GPU
device. This RFC patch series proposes a framework for integrating
use of existing cgroup controllers into device drivers.
The i915 driver is updated in
13 matches
Mail list logo
