Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate how to meld USM and Virtual Memory #635

Open
kbenzie opened this issue Jun 19, 2023 · 5 comments
Open

Investigate how to meld USM and Virtual Memory #635

kbenzie opened this issue Jun 19, 2023 · 5 comments
Labels
memory Memory allocations/transfers/operations umf Unified Malloc Framework (prev. UMA)

Comments

@kbenzie
Copy link
Contributor

kbenzie commented Jun 19, 2023

In #525 a number of virtual memory interfaces are added as part of supporting the sycl_ext_oneapi_virtual_mem extension. Discussion on the PR starting here points out concearns that USM and these new virtual memory interfaces are not currently well integrated.

This issue exists to track the discussion about how to meld the USM and Virtual Memory interfaces to interoperate nicely, likley in the adapter implementations, to retain memory tracking capabilities currently available in USM across all memory interfaces.

@kbenzie kbenzie added memory Memory allocations/transfers/operations umf Unified Malloc Framework (prev. UMA) labels Jun 19, 2023
@igchor
Copy link
Member

igchor commented Jun 27, 2023

In general, what are the current limitations of the virtual memory interfaces vs USM? Sergey mentioned memory pooling and features that are associated with that (memory tracking, etc.) but as I understand there might be more differences.

For example, do we allow calling urEnqueueUSMAdvise or urEnqueueUSMFill on memory that was mapped and allocated using virtual memory interfaces?

@kbenzie
Copy link
Contributor Author

kbenzie commented Jul 3, 2023

For example, do we allow calling urEnqueueUSMAdvise or urEnqueueUSMFill on memory that was mapped and allocated using virtual memory interfaces?

@steffenlarsen what are your thoughts on this question?

@steffenlarsen
Copy link
Contributor

Optimally we would consider any device USM operation valid with a mapped virtual memory pointer. To my knowledge, both L0 and CUDA allow that.

@jandres742
Copy link

In general, what are the current limitations of the virtual memory interfaces vs USM?
For example, do we allow calling urEnqueueUSMAdvise or urEnqueueUSMFill on memory that was mapped and allocated using virtual memory interfaces?

Virtual memory and USM memory just differ on how they are allocated, but after that, they are expected to support same functionality and usage on other commands. That's my understanding on how CUDA supports it and it is how L0 does it.

All that virtual memory does is to grant finer control to applications, but shouldn't limit any functionality.

@vinser52
Copy link
Contributor

I think the main question is how to preserve memory tracking capabilities by UMF. Today UMF tracks its own allocations and later clients might easily get the corresponding pool by ptr and read various pool properties.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
memory Memory allocations/transfers/operations umf Unified Malloc Framework (prev. UMA)
Projects
None yet
Development

No branches or pull requests

5 participants