mechanism for freeing allocations saved for reuse that have not been
used in a given time
Related-To: NEO-13425
Signed-off-by: Dominik Dabek <dominik.dabek@intel.com>
Addresses regressions from the reverted merge
of the tbx fault manager for host memory.
Recursive locking of mutex caused deadlock.
To fix, separate tbx fault data from base
cpu fault data, allowing separate mutexes
for each, eliminating recursive locks on
the same mutex.
By separating, we also help ensure that tbx-related
changes don't affect the original cpu fault manager code
paths.
As an added safe guard preventing critical regressions
and avoiding another auto-revert, the tbx fault manager
is hidden behind a new debug flag which is disabled by default.
Related-To: NEO-12268
Signed-off-by: Jack Myers <jack.myers@intel.com>
Addresses regressions from the reverted merge
of the tbx fault manager for host memory.
This fixes attempts by the tbx fault manager
to protect/unprotect host buffer memory, even
if the host ptr was not driver-allocated.
In the case of the smoke test that triggered
the critical regression, clCreateBuffer was
called with the CL_MEM_USE_HOST_PTR flag.
The subsequent `mprotect` calls on the
provided host ptr then failed.
Related-To: NEO-12268
Signed-off-by: Jack Myers <jack.myers@intel.com>
In TBX mode, the host could not write to host buffers after access from device
code due to the lack of a migration mechanism post-initial TBX upload.
Migration is unnecessary with real hardware, but required for TBX.
This patch introduces a new page fault manager type that extends the original
CPU fault manager, enabling automatic migration of host buffers in TBX mode.
Refactoring was necessary to avoid diamond inheritance, achieved by using a
template parameter as the base class for OS-specific fault managers.
Related-To: NEO-12268
Signed-off-by: Jack Myers <jack.myers@intel.com>
This PR handles the situation in which a component
has reserved a front window space for itself in the external heap,
so that the Compute Runtime cannot access this area.
In such a situation, we perform the following steps:
1. reserve 4GB chunk in heapStandard
2. split our chunk into 2 parts: heapFrontWindow, heapRegular
3. from this point on, map all linearStream allocations in reserved 4GB
chunk
Patch applies to Windows and WSL.
Patch only applies when the bindless global allocator is enabled.
Related-To: HSD-16025889919
Signed-off-by: Fabian Zwoliński <fabian.zwolinski@intel.com>
Calculate available memory for usm device reuse based as (total device
memory - used memory) * fraction for reuse.
Use sys mem allocs for devices without local memory.
Related-To: NEO-12902
Signed-off-by: Dominik Dabek <dominik.dabek@intel.com>
Add tracking of memory used for usm reuse mechanism when multiple cl
contexts are used.
Tracking for device added to NEO::Device, for host added to
NEO::MemoryManager.
This fixes usm reuse using x% of memory per each context instead of
globally.
Related-To: NEO-13308
Signed-off-by: Dominik Dabek <dominik.dabek@intel.com>
if limiting, disable device usm reuse (set max size to 0)
do not reserve vector for allocation infos if reuse is disabled
Related-To: NEO-12924
Signed-off-by: Dominik Dabek <dominik.dabek@intel.com>
Fix the PAT-index reporting in logger as currently on Windows reported
values are simply wrong.
The changed logic dependends on `RootDeviceEnvironment` and in order to
avoid introducing such dependencies into logger.[ch] the
`logAllocation()` is no longer a member of `FileLogger` but
a free-function instead (and a separate .cpp file). This is important
because the source files `logger.[ch]` are also used by ocloc library
and there is no point to contaminate ocloc code structure with
unnecessary dependencies.
Related-To: NEO-9421
Signed-off-by: Maciej Bielski <maciej.bielski@intel.com>
- bitset is 64 bit in size, context ids may go beyond that limit
when multiple devices are available
- this change subtracts contextId of first context for a given root
device - tracked state dirty contexts ids are now zero-based
Resolves: GSD-10025
Signed-off-by: Mateusz Hoppe <mateusz.hoppe@intel.com>
