From: bugzilla-daemon@kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 214425] [drm][amdgpu][TTM] Page pool memory never gets freed
Date: Sat, 15 Oct 2022 15:05:38 +0000 [thread overview]
Message-ID: <bug-214425-2300-Ly1EhtsZP3@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-214425-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=214425
--- Comment #3 from Rafael Ristovski (rafael.ristovski@gmail.com) ---
(In reply to Martin Doucha from comment #2)
> (In reply to Rafael Ristovski from comment #1)
> > According to amdgpu devs, this is a feature where the allocated pages are
> > kept around in case they are needed later on. TTM is able to release the
> > memory in case the memory pressure increases.
>
> I understand the logic behind keeping idle buffers allocated for a while.
> But it does not make sense to keep them for hours after last use and the
> release mechanism on increased memory pressure does not seem to be working.
>
> When I run a large compilation overnight, starting from a fresh reboot and
> shutting down all graphics software including the X server, I'll often come
> back in the morning to find that 70% of all RAM is allocated in idle TTM
> buffers and GCC is stuck swapping for hours. The TTM buffers were likely
> allocated by some GPU-accelerated build computation halfway through the
> night. But this is harder to reproduce than the games I've mentioned in the
> initial bugreport.
Indeed, I too run into situations where even if I purposefully trigger an OOM
situation just to get the TTM "cache" to evict itself through memory pressure,
_it still does not end up releasing all of the memory_.
There are also the following two sysfs files, simply reading them triggers an
eviction of GTT/VRAM:
> cat /sys/kernel/debug/dri/0/amdgpu_evict_vram
> cat /sys/kernel/debug/dri/0/amdgpu_evict_gtt
this can be confirmed as working with tools like `radeontop`/`nvtop`.
However, this once again does not release the TTM buffers.
As you can see in the issue I linked, I never got a reply about a mechanism to
manually release TTM memory. I will attempt coercing an answer on IRC, perhaps
I will have better luck asking directly there.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2022-10-15 15:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 21:09 [Bug 214425] New: [drm][amdgpu][TTM] Page pool memory never gets freed bugzilla-daemon
2022-10-15 14:34 ` [Bug 214425] " bugzilla-daemon
2022-10-15 14:47 ` bugzilla-daemon
2022-10-15 15:05 ` bugzilla-daemon [this message]
2022-10-15 16:14 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-214425-2300-Ly1EhtsZP3@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.