Limiting CPU Usage of a Third‑Party SDK with cgroup and cpuset on Linux

Hello everyone, I'm Fei! In this post I share how we tested the performance of a CPU‑intensive third‑party SDK and needed to evaluate its CPU usage to estimate the number of servers required for production.

We ran the SDK on a 16‑core machine, but observed that it only saturated one core in the first half of execution and all 16 cores later, making simple CPU‑time multiplication inaccurate.

First, we tried NUMA binding, but each NUMA node contains eight cores, so it still didn't give precise control.

Next we turned to cgroup. By creating a cpu,cpuacct cgroup and adjusting cpu.cfs_quota_us and cpu.cfs_period_us , we can limit the total CPU time the group may use, effectively restricting the process to one core.

# cd /sys/fs/cgroup/cpu,cpuacct
# mkdir test
# cd test

After creating the group, we inspected the files it generated. The key files are cfs_period_us (the length of the scheduling period) and cfs_quota_us (the amount of CPU time allowed within that period).

To limit the process to one core we set both values to 500 000 µs (500 ms):

# echo 500000 > cpu.cfs_quota_us  // 500 ms
# echo 500000 > cpu.cfs_period_us // 500 ms

Adding a process to the cgroup is done by writing its PID to cgroup.procs . Adding the parent bash process ensures that any child processes inherit the limit.

# echo $$
16403
sh -c "echo 16403 > cgroup.procs"

We then used the stress tool to generate CPU load:

# stress -c 4

The observed CPU usage stayed within a single core, confirming the limit.

However, the load was still spread across different cores. To pin the execution to a specific core we explored the cpuset controller.

# ll /sys/fs/cgroup/
# ... cpuset // the directory we need

We removed the previous cpu,cpuacct group and created a new cpuset group:

# cd /sys/fs/cgroup/cpuset
# mkdir test && cd test
# echo "0" > cpuset.cpus   // restrict to CPU 0
# echo 0 > cpuset.mems
# echo $$ > cgroup.procs

Running stress -c 4 again showed that both the total CPU consumption and the specific core (CPU 0) were tightly controlled, as verified by monitoring tools and screenshots.

With this method we accurately measured the SDK’s CPU consumption and can now estimate the required number of servers for production deployment.