<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2023-05-03 11:11, Thomas Hellström
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:888841c4-7bd4-8174-7786-033715c995c6@linux.intel.com">Hi,
Maarten
<br>
<br>
On 5/3/23 10:34, Maarten Lankhorst wrote:
<br>
<blockquote type="cite">This allows the drm cgroup controller to
return no space is available..
<br>
<br>
XXX: This is a hopeless simplification that changes behavior,
and
<br>
returns -ENOSPC even if we could evict ourselves from the
current
<br>
cgroup.
<br>
<br>
Ideally, the eviction code becomes cgroup aware, and will force
eviction
<br>
from the current cgroup or its parents.
<br>
<br>
Signed-off-by: Maarten Lankhorst
<a class="moz-txt-link-rfc2396E" href="mailto:maarten.lankhorst@linux.intel.com"><maarten.lankhorst@linux.intel.com></a>
<br>
</blockquote>
<br>
Thinking of the shrinker analogy, do non-cgroup aware shrinkers
just shrink blindly or do they reject shrinking like this patch
when a cgroup limit is reached?
<br>
</blockquote>
<p>When I made the cgroup controller return -ENOSPC I just hit an
infinite loop since it sees enough memory is free and tries to
allocate memory again. Hence the -EAGAIN handling here. It returns
-ENOSPC, without the infinite looping.</p>
<p>I think there should be 2 code paths:</p>
<p>- OOM, generic case: Handle like we do now. No need for special
cgroup handling needed right now.</p>
<p>Might change if we implement cgroup memory semantics. See the
memory section of Documentation/admin-guide/cgroup-v2.rst <br>
</p>
<p>It could be useful regardless.<br>
</p>
<pre>- OOM, cgroup limit reached: Check for each BO if it's valuable to evict to unblock the relevant limit.
/ cg1.0
root - cg1 -- cg1.1
\ \ cg1.2
\ cg2
If we hit the cg limit in cg1.0 for only cg1.0, it doesn't make sense to evict from any other cgroup.
If we hit the limit in cg1.0 for the entirety of cg1, it makes sense to evict from any of the cg1 nodes, but not from cg2.
This should be relatively straightforward to implement. We identify which cgroup hit a limit, and then let the shrinker
run only on that cgroup and its childs.
This could be simplified to the OOM generic case, for root/NULL cg.
~Maarten
</pre>
</body>
</html>