kernel: CONFIG_CFS_BANDWIDTH is off, so cpu.max cannot cap an execution
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 62/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- linux, rust
- Domain
- operating-systems
Research direction
The change is a kernel config option, so start at the microVM kernel config under kernel/config-microvm and find the # CONFIG_CFS_BANDWIDTH is not set line. Enable it, then confirm that writing cpu.max into a guest cgroup succeeds on a booted kernel. Done means the option is set and the reporter's cpu.max write no longer fails; check whether the build pipeline also needs a rebuild step.
Written by the indexing model from the issue text.
Description
What
An adapter that runs sandboxed executions in the guest can cap memory.max and pids.max of an execution's cgroup but not its CPU time: the kernel in kernel/config-microvm has # CONFIG_CFS_BANDWIDTH is not set, so writing cpu.max fails.
Why this might matter here
#912 discusses the cost of one cgroup per execution and the limits of one cgroup for all executions. A per-execution CPU cap would need cpu.max, which needs this option. I did not find an issue or PR that asks for it (searched cpu.max, CFS, CPU limit cgroup).
Evidence (one machine, an external adapter, not the upstream agent)
With a kernel built from the same 6.18.38 sources and patches plus CONFIG_CFS_BANDWIDTH=y, a guest agent that writes cpu.max into an execution's cgroup limited a busy loop to 0.51 CPU for a 50 % limit (1.00 CPU with no limit). With the upstream release kernel the same request fails at start. I have not measured the size or boot-time cost of the option.
Proposal
Enable the option (one line, PR follows). Whether the upstream managed agent should expose cpu.max is a separate question; I am not asking for that here.
- Dominant language
- Rust
- Stars
- 758
- Forks
- 48
- Avg merge
- 17h 50m
- Merged PRs (30d)
- 450
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/nvx
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
microsoft/nvx#1172 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
microsoft/nvx#1151 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
microsoft/nvx#1147 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
microsoft/nvx#1146 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
microsoft/nvx#1144 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
DioxusLabs/blitz#1371 ·
Maintainers usually reply within 1 day
-
follow-up
Difficulty 2/5 Half a day Newbie friendliness 62/100
carrick-sh/carrick#1494 ·
Maintainers usually reply within 1 day
-
test(hydro_std): track_membership join and leave are untestedPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
hydro-project/hydro#3289 ·
Maintainers usually reply within 1 day
-
diagram-bug good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
enhapu-afk/omaspec#4 ·