bug(wrap): add oom_score_adj to exec specs#124
Conversation
| // If not specified, we do want to pro-actively set this value to the | ||
| // kernel-default of zero, else the subprocess inherits the styrolite | ||
| // oom score (which is typcially set to a very low value). | ||
| fs::write("/proc/self/oom_score_adj", self.exec.oom_score_adj.unwrap_or(0).to_string())?; |
There was a problem hiding this comment.
Might as well set this in AttachRequest::wrap() as well, in roughly the same spot.
There was a problem hiding this comment.
In this case, though, I imagine it would make sense to only set the score if it is specified. In the case of None we would leave it alone, as a running process has already had its oom score set?
In CreateRequest, we are explicit in setting the oom score to zero because the process is fresh, and otherwise linux grabs the value from the parent (which we do not want).
There was a problem hiding this comment.
That's a good point, and on reflection, in both cases, I think we should only set if Some - the force to 0 as a default can be done in the layer above, by the caller, if desired, in that case, and styrolite doesn't have to augur intent around defaults/can be "dumb" about it.
alexandermerritt
force-pushed
the
alexm/bug-oom-score-2198
branch
from
47150a3 to
ab8e549
Compare
This value can be forwarded from a CRI and ensures an appropriate OOM score is set for processes in cases where high memory use is seen. Signed-off-by: Alexander Merritt <alexander@edera.dev>
alexandermerritt
force-pushed
the
alexm/bug-oom-score-2198
branch
from
ab8e549 to
a65cb4a
Compare
2 participants
Include consideration of an OOM score adjustment in the process spec. CRI from Kubernetes expects to initialize this depending on how the memory limits are configured. If not specified, we default to the kernel-default of zero.