Am 01.09.21 um 13:20 schrieb Gal Pressman:
On 24/08/2021 20:32, Jason Gunthorpe wrote:
On Tue, Aug 24, 2021 at 10:27:23AM -0700, John Hubbard wrote:
On 8/24/21 2:32 AM, Christian König wrote:
Am 24.08.21 um 11:06 schrieb Gal Pressman:
On 23/08/2021 13:43, Christian König wrote:
Am
On Wed, Aug 25, 2021 at 6:14 PM Christian König
wrote:
>
> Am 25.08.21 um 16:47 schrieb Jason Gunthorpe:
> > On Wed, Aug 25, 2021 at 03:51:14PM +0200, Christian König wrote:
> >> Am 25.08.21 um 14:38 schrieb Jason Gunthorpe:
> >>> On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
>
On Wed, Aug 25, 2021 at 05:14:06PM +0200, Christian König wrote:
> Yeah, that's exactly what I'm talking about by adding cgroup or similar. You
> need a knob to control this.
We have the pinned memory ulimit today.
A pinned memory cgroup might be interesting, but even containrs are
covered
Am 25.08.21 um 16:47 schrieb Jason Gunthorpe:
On Wed, Aug 25, 2021 at 03:51:14PM +0200, Christian König wrote:
Am 25.08.21 um 14:38 schrieb Jason Gunthorpe:
On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
On Wed, Aug 25, 2021 at
On Wed, Aug 25, 2021 at 03:51:14PM +0200, Christian König wrote:
> Am 25.08.21 um 14:38 schrieb Jason Gunthorpe:
> > On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
> > > Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
> > > > On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian
Am 25.08.21 um 14:38 schrieb Jason Gunthorpe:
On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian König wrote:
The only real option where you could do P2P with buffer pinning are
On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian König wrote:
> The only real option where you could do P2P with buffer pinning are those
> compute boards where we know that everything is always accessible to
> everybody and we will never need to migrate anything. But even then you want
> some
On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
> Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
> > On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian König wrote:
> >
> > > The only real option where you could do P2P with buffer pinning are those
> > > compute boards where we
Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian König wrote:
The only real option where you could do P2P with buffer pinning are those
compute boards where we know that everything is always accessible to
everybody and we will never need to
On 8/24/21 11:17 PM, Christian König wrote:
...
I think it depends on the user, if the user creates memory which is
permanently located on the GPU then it should be pinnable in this way
without force migration. But if the memory is inherently migratable
then it just cannot be pinned in the GPU
Am 24.08.21 um 19:32 schrieb Jason Gunthorpe:
On Tue, Aug 24, 2021 at 10:27:23AM -0700, John Hubbard wrote:
On 8/24/21 2:32 AM, Christian König wrote:
Am 24.08.21 um 11:06 schrieb Gal Pressman:
On 23/08/2021 13:43, Christian König wrote:
Am 21.08.21 um 11:16 schrieb Gal Pressman:
On
RAMEWORK
> ; dri-devel de...@lists.freedesktop.org>; Linux Kernel Mailing List
> ; linux-rdma ;
> Gabbay,
> Oded (Habana) ; Tayar, Tomer (Habana) ;
> Yossi Leybovich ; Alexander
> Matushevsky ; Leon Romanovsky ; Xiong,
> Jianxin
> Subject: Re: [RFC] Make use of non
On Tue, Aug 24, 2021 at 3:16 PM Dave Airlie wrote:
>
> On Wed, 25 Aug 2021 at 03:36, John Hubbard wrote:
> >
> > On 8/24/21 10:32 AM, Jason Gunthorpe wrote:
> > ...
> > >>> And yes at least for the amdgpu driver we migrate the memory to host
> > >>> memory as soon as it is pinned and I would
On Wed, Aug 25, 2021 at 05:15:52AM +1000, Dave Airlie wrote:
> On Wed, 25 Aug 2021 at 03:36, John Hubbard wrote:
> >
> > On 8/24/21 10:32 AM, Jason Gunthorpe wrote:
> > ...
> > >>> And yes at least for the amdgpu driver we migrate the memory to host
> > >>> memory as soon as it is pinned and I
On Wed, 25 Aug 2021 at 03:36, John Hubbard wrote:
>
> On 8/24/21 10:32 AM, Jason Gunthorpe wrote:
> ...
> >>> And yes at least for the amdgpu driver we migrate the memory to host
> >>> memory as soon as it is pinned and I would expect that other GPU drivers
> >>> do something similar.
> >>
> >>
On 8/24/21 10:32 AM, Jason Gunthorpe wrote:
...
And yes at least for the amdgpu driver we migrate the memory to host
memory as soon as it is pinned and I would expect that other GPU drivers
do something similar.
Well...for many topologies, migrating to host memory will result in a
dramatically
On Tue, Aug 24, 2021 at 10:27:23AM -0700, John Hubbard wrote:
> On 8/24/21 2:32 AM, Christian König wrote:
> > Am 24.08.21 um 11:06 schrieb Gal Pressman:
> > > On 23/08/2021 13:43, Christian König wrote:
> > > > Am 21.08.21 um 11:16 schrieb Gal Pressman:
> > > > > On 20/08/2021 17:32, Jason
On 8/24/21 2:32 AM, Christian König wrote:
Am 24.08.21 um 11:06 schrieb Gal Pressman:
On 23/08/2021 13:43, Christian König wrote:
Am 21.08.21 um 11:16 schrieb Gal Pressman:
On 20/08/2021 17:32, Jason Gunthorpe wrote:
On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:
...
IIUC,
Am 24.08.21 um 11:06 schrieb Gal Pressman:
On 23/08/2021 13:43, Christian König wrote:
Am 21.08.21 um 11:16 schrieb Gal Pressman:
On 20/08/2021 17:32, Jason Gunthorpe wrote:
On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:
Though it would've been nicer if we could agree on a
Am 21.08.21 um 11:16 schrieb Gal Pressman:
On 20/08/2021 17:32, Jason Gunthorpe wrote:
On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:
Though it would've been nicer if we could agree on a solution that could work
for more than 1-2 RDMA devices, using the existing tools the RDMA
On 20/08/2021 17:32, Jason Gunthorpe wrote:
> On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:
>
>> Though it would've been nicer if we could agree on a solution that could work
>> for more than 1-2 RDMA devices, using the existing tools the RDMA subsystem
>> has.
>
> I don't think
On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:
> Though it would've been nicer if we could agree on a solution that could work
> for more than 1-2 RDMA devices, using the existing tools the RDMA subsystem
> has.
I don't think it can really be done, revoke is necessary, and isn't
On Fri, Aug 20, 2021 at 09:25:30AM +0200, Daniel Vetter wrote:
> On Fri, Aug 20, 2021 at 1:06 AM Jason Gunthorpe wrote:
> > On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> > > >
> > > > Hey all,
> > > >
> > > > Currently,
On Fri, Aug 20, 2021 at 1:06 AM Jason Gunthorpe wrote:
> On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> > >
> > > Hey all,
> > >
> > > Currently, the RDMA subsystem can only work with dynamic dmabuf
> > > attachments,
On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> >
> > Hey all,
> >
> > Currently, the RDMA subsystem can only work with dynamic dmabuf
> > attachments, which requires the RDMA device to support on-demand-paging
> > (ODP) which
On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
>
> Hey all,
>
> Currently, the RDMA subsystem can only work with dynamic dmabuf
> attachments, which requires the RDMA device to support on-demand-paging
> (ODP) which is not common on most devices (only supported by mlx5).
>
> While the
On 18/08/2021 11:00, Christian König wrote:
> Am 18.08.21 um 09:43 schrieb Gal Pressman:
>> Hey all,
>>
>> Currently, the RDMA subsystem can only work with dynamic dmabuf
>> attachments, which requires the RDMA device to support on-demand-paging
>> (ODP) which is not common on most devices (only
Am 18.08.21 um 09:43 schrieb Gal Pressman:
Hey all,
Currently, the RDMA subsystem can only work with dynamic dmabuf
attachments, which requires the RDMA device to support on-demand-paging
(ODP) which is not common on most devices (only supported by mlx5).
While the dynamic requirement makes
28 matches
Mail list logo
