oneapi-src / unified-memory-framework

A library for constructing allocators and memory pools. It also contains broadly useful abstractions and utilities for memory management. UMF allows users to manage multiple memory pools characterized by different attributes, allowing certain allocation types to be isolated from others and allocated using different hardware resources as required.
https://oneapi-src.github.io/unified-memory-framework/
Other
31 stars 23 forks source link

Expose umfMemoryTrackerGetAllocInfo #686

Open igchor opened 3 weeks ago

igchor commented 3 weeks ago

Expose a function that returns information about coarse-grain allocations, including:

Rationale

UR validation layer uses urUSMGetMemAllocInfo to obtain information about size and base address for an allocation to do bounds checking: https://github.com/oneapi-src/unified-runtime/blob/main/source/loader/layers/validation/ur_validation_layer.cpp#L41 For L0 adapters, urUSMGetMemAllocInfo gets this information by asking the driver which is costly: https://github.com/oneapi-src/unified-runtime/blob/d61cf6680c7f620bd5092e2bb22524106fbdef63/source/adapters/level_zero/usm.cpp#L621

We should expose a function that would allow users to query this information directly from UMF.

API Changes

struct umf_alloc_info_t {
   void* baseAddr;
   size_t size;
   umf_memory_pool_handle_t hPool;
};

umf_result_t umfGetAllocInfo(void *ptr, umf_alloc_info_t* info);

Implementation details

Use umfMemoryTrackerGetAllocInfo

Meta

vinser52 commented 3 weeks ago

I agree with the problem description. UMF tacker has all the required information and UR can ask UMF instead of L0 and UMF should perform better than L0. Regarding the solution, we should design the API before implementing it - need to discuss if exposing umfMemoryTrackerGetAllocInfo is the best way (perhaps yes). As a first, we need to capture all relevant use cases and their requirements, e.g. MPI needs functionality to get allocation properties. We will schedule this topic at UMF technical meeting.