: [RFC PATCH 0/6] Supporting GMEM (generalized memory
management) for external memory devices
Hi Oak,
yeah, #4 is indeed a really good point and I think Felix will agree to that as
well.
HMM is basically still missing a way to advise device attributes for the CPU
address space. Both migration
tools
>>> for address space mirroring and migration helpers. For #3, since we have a
>>> common drm/buddy layer, I don't think it is a big problem for driver writer
>>> now.
>>>> I do see #4 is something you solved more beautifully, requires new system
>&
inux.intel.com; zhi.a.w...@intel.com;
> intel-gvt-...@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; tvrtko.ursu...@linux.intel.com; Danilo
> Krummrich ; Daniel Vetter ; Zeng,
> Oak
...@nvidia.com;
felix.kuehl...@amd.com; Wang, Zhi A;
mgor...@suse.de
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory
management) for external memory devices
Hi Oak,
yeah, #4 is indeed a really good point and I think Felix will agree to that as
well.
HMM is basically still missing
On 01.12.23 03:44, zhuweixi wrote:
Thanks!
I hope you understood that that was a joke :)
I am planning to present GMEM in Linux MM Alignment Sessions so I can collect
more input from the mm developers.
Sounds good. But please try inviting key HMM/driver developer as well.
Most of the
m; intel-gvt-...@lists.freedesktop.org;
>> ogab...@kernel.org; leo...@nvidia.com; mgor...@suse.de
>> Subject: RE: [RFC PATCH 0/6] Supporting GMEM (generalized memory
>> management) for external memory devices
>>
>> Glad to know that there is a common demand for a ne
t; jgli...@redhat.com; dri-devel@lists.freedesktop.org; z...@nvidia.com;
> Vivi, Rodrigo ; alexander.deuc...@amd.com;
> leo...@nvidia.com; felix.kuehl...@amd.com; Wang, Zhi A
> ; mgor...@suse.de
> Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management)
> for e
November 28, 2023 8:09 AM
> >> To: Weixi Zhu ; linux...@kvack.org; linux-
> >> ker...@vger.kernel.org; a...@linux-foundation.org; Danilo Krummrich
> >> ; Dave Airlie ; Daniel Vetter
> >>
> >> Cc: dri-devel@lists.freedesktop.org; leo...@nvidia.com;
&
-...@lists.freedesktop.org; jani.nik...@linux.intel.com;
joonas.lahti...@linux.intel.com; rodrigo.v...@intel.com;
tvrtko.ursu...@linux.intel.com
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management)
for external memory devices
On 29.11.23 09:27, zhuweixi wrote:
> Glad to h
ists.freedesktop.org; jani.nik...@linux.intel.com;
joonas.lahti...@linux.intel.com; rodrigo.v...@intel.com;
tvrtko.ursu...@linux.intel.com; Danilo Krummrich ; Daniel
Vetter ; Zeng, Oak
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management)
for external memory devices
On 29.11.23 09:27, zhuweixi wrote:
Glad to hear that more sharable code is desirable.
IMHO, for a common MM subsystem, it is more beneficial for
GMEM to extend core MM instead of building a separate one.
More core-mm complexity, awesome, we all love that! ;)
--
Cheers,
David / dhildenb
intel.com; joonas.lahti...@linux.intel.com;
rodrigo.v...@intel.com; tvrtko.ursu...@linux.intel.com
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory
management) for external memory devices
On Tue, 28 Nov 2023 at 23:07, Christian König wrote:
Am 28.11.23 um 13:50 schrieb Weixi Zhu:
org; jgli...@redhat.com;
dri-devel@lists.freedesktop.org; z...@nvidia.com; Vivi, Rodrigo
; alexander.deuc...@amd.com; leo...@nvidia.com;
felix.kuehl...@amd.com; Wang, Zhi A ; mgor...@suse.de
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management)
for external memory devices
Hi
..@amd.com;
alexander.deuc...@amd.com; ogab...@kernel.org
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory
management) for external memory devices
Adding a few missing important people to the explicit to list.
Am 28.11.23 um 13:50 schrieb Weixi Zhu:
The problem:
Accelerator driver
.@intel.com; intel-gvt-...@lists.freedesktop.org;
intel-...@lists.freedesktop.org; jani.nik...@linux.intel.com;
joonas.lahti...@linux.intel.com; rodrigo.v...@intel.com;
tvrtko.ursu...@linux.intel.com
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management)
for external memory device
ts.freedesktop.org;
> tvrtko.ursu...@linux.intel.com; felix.kuehl...@amd.com; xinhui@amd.com;
> alexander.deuc...@amd.com; ogab...@kernel.org
> Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory
> management) for external memory devices
>
> Adding a few missing impor
drigo.v...@intel.com;
tvrtko.ursu...@linux.intel.com
Subject: Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management)
for external memory devices
On Tue, 28 Nov 2023 at 23:07, Christian König wrote:
Am 28.11.23 um 13:50 schrieb Weixi Zhu:
The problem:
Accelerator driver developers ar
PATCH 0/6] Supporting GMEM (generalized memory management)
for external memory devices
On Tue, 28 Nov 2023 at 23:07, Christian König wrote:
>
> Am 28.11.23 um 13:50 schrieb Weixi Zhu:
> > The problem:
> >
> > Accelerator driver developers are forced to reinvent exter
On Tue, 28 Nov 2023 at 23:07, Christian König wrote:
>
> Am 28.11.23 um 13:50 schrieb Weixi Zhu:
> > The problem:
> >
> > Accelerator driver developers are forced to reinvent external MM subsystems
> > case by case, because Linux core MM only considers host memory resources.
> > These reinvented
The problem:
Accelerator driver developers are forced to reinvent external MM subsystems
case by case, because Linux core MM only considers host memory resources.
These reinvented MM subsystems have similar orders of magnitude of LoC as
Linux MM (80K), e.g. Nvidia-UVM has 70K, AMD GPU has 14K and
Adding a few missing important people to the explicit to list.
Am 28.11.23 um 13:50 schrieb Weixi Zhu:
The problem:
Accelerator driver developers are forced to reinvent external MM subsystems
case by case, because Linux core MM only considers host memory resources.
These reinvented MM
Am 28.11.23 um 13:50 schrieb Weixi Zhu:
The problem:
Accelerator driver developers are forced to reinvent external MM subsystems
case by case, because Linux core MM only considers host memory resources.
These reinvented MM subsystems have similar orders of magnitude of LoC as
Linux MM (80K),
22 matches
Mail list logo
