mirror of https://git.FreeBSD.org/doc.git
releases/15.0R/relnotes: Trim description of GPU slowness and VM domainset fixes
Readers interested can look up the related commits, and I've written similar descriptions in the Q3 Status Reports. Sponsored by: The FreeBSD Foundation
This commit is contained in:
parent
d260183938
commit
9481c40a80
|
|
@ -881,15 +881,8 @@ gitref:960ee8094913[repository=src].
|
|||
{{< sponsored "The FreeBSD Foundation" >}}
|
||||
|
||||
Gradual slowdowns and freezes experienced by owners of some AMD GPUs using the amdgpu DRM driver from the `drm-kmod` ports, starting with v5.15 (`graphics/drm-515-kmod` port), have been fixed.
|
||||
In particular, owners of graphics cards with Green Sardine, Polaris 10 and 20 chips were known to be affected.
|
||||
In particular, owners of graphics cards with Green Sardine, Polaris 10 and 20 and Vega chips were known to be affected.
|
||||
Recent Intel-based GPUs (gen 13+) may also have been affected.
|
||||
The main cause is that the Linux's DRM subsystem's TTM component frequently requests memory that is physically contiguous although this property is not strictly necessary, and the kernel was trying too hard to fulfill them, leading to longer and more frequent freezes as physical memory got more fragmented over time.
|
||||
In the LinuxKPI, `linux_alloc_pages()` now honors `__GFP_NORETRY` by not trying to break superpage reservations or defragment memory if the request for contiguous physical memory cannot be fulfilled immediately.
|
||||
Another cause was that, during recent LinuxKPI evolution, `kmalloc()` was changed to always return physically contiguous memory as it does in Linux, but unfortunately `kvzalloc()` relied on `kmalloc()` and this was not changed, effectively turning all large memory allocations of zeroed pages into costly physically contiguous ones.
|
||||
On allocation success, the TTM component sets page attributes unconditionally, regardless of whether they are already in place, which triggerred expensive TLB shootdowns even when not necessary.
|
||||
Yet another cause was a flaw in the code iterating over memory domains (NUMA) leading to re-examining the same domain multiple times even if it could not fulfill the contiguous allocation request.
|
||||
More details about this are given below.
|
||||
Finally, some useless temporary physically contiguous allocation routinely performed in the case of Carrizo, Polaris and Vega M based AMD GPUs was converted to a regular one in the DRM drivers from the latest `drm-*-kmod` ports.
|
||||
gitref:718d1928f874[repository=src],
|
||||
gitref:4ca9190251bb[repository=src],
|
||||
gitref:986edb19a49c[repository=src],
|
||||
|
|
@ -897,12 +890,7 @@ gitref:9d1f3ce79d85[repository=src],
|
|||
gitref:da257e519bc0[repository=src]
|
||||
{{< sponsored "The FreeBSD Foundation" >}}
|
||||
|
||||
Multiple flaws were fixed in the code iterating over memory domains (NUMA).
|
||||
A failing contiguous allocation request would lead to re-examine the same domain multiple times even if it could not fulfill the request, wasting time and increasing allocation latency.
|
||||
This would happen up to 4 times for the common case of a single memory domain and the "first touch" policy.
|
||||
The first domain selected by all allocation policies, except "first touch" in some cases, would be considered even if it was not in the allowed domains mask or had been marked as to ignore in a previous attempt with the same iterator.
|
||||
After a failed first attempt and sleeping, waiting allocations would restart with the policy's first domain even if that one was still in a low memory condition.
|
||||
Finally, the "interleave" policy would reset the iterator index when restarting, effectively resetting the initial domain in the round-robin phase that happens after allocation from the first domain failed.
|
||||
The code iterating over memory domains (NUMA) was improved and fixed in a number of ways, resulting in particular in decreased latency for some graphical operations with DRM drivers.
|
||||
gitref:da257e519bc0[repository=src],
|
||||
gitref:83ad6d8d8eee[repository=src],
|
||||
gitref:b15ff7214020[repository=src]
|
||||
|
|
|
|||
Loading…
Reference in New Issue