Fix TONGA_PAGE_SIZE value and move it to libhsakmt.h for usiing it
consistently in all places that require the same alignment for the
same reason. Create a generic alignment helper macro to replace some
incorrect hand-coded size alignments.
Move virtual address and size alignments down into aperture management
functions. Alignment is a per-aperture property that is set during
fmm_init_process_apertures. Doing the alignment there ensures that
all allocations in the same aperture are aligned the same way. Finding
objects by size and address can take the alignment into account.
Also align the size of physical allocations to back aligned virtual
address allocations. CPU mappings do not need to be aligned.
Map anonymous pages over released memory mappings to allow the
backing pages to be released, while keeping the address space
reserved.
Add alignment parameter to free_exec_aligned_memory_gpu to match the
interface of allocate_exec_aligned_memory_cpu. It doesn't make sense
to allow an alignment parameter in one but assume a specific
alignment in the other.
Change-Id: I74226ca6938f4948f643e5aee1d474720cd89e78
Patch submitted by Besar Wicaksono
1. Bug on detecting local memory size interpreted as 32 bit value
instead of 64. The bug causes thunk to go into an infinite loop trying
to reserve virtual address range for dgpu system memory.
2. SIMD count in the node property is 0. Runtime use this attribute to
find a gpu device.
Regarding other attributes of intel+tonga topology, Harish started a
discussion on August iirc, could you please share an update ?
This would help me progress with more tests such as scratch memory,
which require the scratch aperture information in order to construct a
buffer srd in gpuvm space.
3. Bug on releasing memory via fmm_release, where no actual release is
being done. The vm_object can't be found because the memory size does
not match due to the allocation padded the size with 32KB.
4. Pointer arithmetic on vm_area allocation/release. The value of
vm_area_t::end seems to be interpreted inconsistently whether it is
(start + size -1) or (start + size).
One example of potential issue I see is the logic could report
larger size of the hole in the vm area list.
5. Resource cleanup on multiple library load/unload within a single
process.
- Any memory allocation on subsequent library load will result
an error "va above limit". To my understanding this is due to
the reserved memory for the system memory not being released on unload.
- The static variable events_page needs to be invalidated
appropriately on library unload so the next load could
reinitialize it.
6. Could you please update if AQL queue is ready to test with the stg
kfd/kmt ?
7. The system memory allocation with size larger than 32KB seems to be
padded by an extra 32KB. I was wondering if we could remove this
overhead.
Change-Id: I039988d36637525089c7569dc3b77e58750e2121
Ben Goz
Harish Kasiviswanathan
Felix Kuehling
shaoyunl
Oded Gabbay
Alexey Skidanov
Andrew Lewycky