Skip to content

linux: teach uv_get_constrained_memory() cgroupsv2 - #3744

Merged
bnoordhuis merged 1 commit into
libuv:v1.xfrom
bnoordhuis:fix2315
Sep 15, 2022
Merged

bnoordhuis merged 1 commit into
libuv:v1.xfrom
bnoordhuis:fix2315

Conversation

@bnoordhuis

Copy link
Copy Markdown
Member

Fixes: #2315

cc @maleadt - I figured it'd be easier to type it out than having you jump through more hoops.

Comment thread src/unix/linux-core.c Outdated

@maleadt maleadt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The simplification here is that you assume cgroupv2 to be mounted at /sys/fs/cgroup, and avoid parsing mountinfo. That's not technically correct, but then again I haven't seen cgroupv2 be mounted anywhere else, so maybe it's fine to go with the simpler solution until somebody complains. The only exception is the hybrid cgroupv1+cgroupv2 set-up, which mounted the v2 hierarchy at /sys/fs/cgroup/unified, but that was a transitional solution, and the fallback still works.

@maleadt

maleadt commented Sep 12, 2022

Copy link
Copy Markdown
Contributor

So do we go ahead with this PR, @bnoordhuis?

@bnoordhuis

Copy link
Copy Markdown
Member Author

I'm waiting for a review from @vtjnash or another maintainer.

Comment thread src/unix/linux-core.c

@vtjnash vtjnash left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This SGTM

@maleadt

maleadt commented Sep 16, 2022

Copy link
Copy Markdown
Contributor

Great, thanks @bnoordhuis!

In addition to memory.max/memory.high, we probably also need a way to expose memory.current (because uv_get_free_memory currently does not reflect any cgroup constraint). What about adding uv_get_available_memory that queries memory.current or falls back to uv_get_free_memory (if unconstrained)? It seems like that would pair well: uv_get_memory_constrained/uv_get_memory_available cfr. uv_get_memory_total/uv_get_memory_free.

Comment thread src/unix/linux-core.c
sscanf(buf, "%" PRIu64, &rc);
if (1 != sscanf(buf, "%" PRIu64, &rc))
if (0 == strcmp(buf, "max\n"))
rc = ~0ull;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bnoordhuis I just noticed that this returns -1 when no limit is set. The documentation currently states that 0 is returned for both no and unknown limits. Do you want to keep it like this (being able to discern between both cases) and update the documentation, or return 0 from here as well?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation is ambiguously worded.

"If there is no such constraint, or the constraint is unknown" should say "if there is no constraining mechanism, or the constraint is unknown" but there is a mechanism in effect and the constraint is known, it's set to the max.

I will say that Node.js currently gets it wrong. It seems to assume that if uv_get_constrained_memory() returns non-zero, that implicitly means it's less than uv_get_free_memory() or uv_get_total_memory(). Not strictly always true.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it OK to mention the return value for no limit/max in the documentation? I've updated #3753.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

uv_get_constrained_memory does not seem to work? (checked under cgroup2)

3 participants