Add the process id to the desired cgroup’s cgroup.procs file.
# create cgroup
sudo mkdir /sys/fs/cgroup/testgroup
# enable cpu interface
echo "+cpu" | sudo tee -a /sys/fs/cgroup/cgroup.subtree_control
# enable cpuset interface
echo "+cpuset" | sudo tee -a /sys/fs/cgroup/cgroup.subtree_control
# add current process to cgroup
echo "$$" | sudo tee -a /sys/fs/cgroup/testgroup/cgroup.procs
What happend to the prompts?
Prompts were an interesting concept but I’ve decided not to pursue them at this time. This is mainly a choice in how I want to spend my time.
At the end of the day, what do I want to accomplish? My main goal is to produce applications and libraries. Prompts would take my focus away from this goal.
The basic commands are nearly identical to the commands you would use to build a container with dockerd(moby). The main difference is that unlike dockerd, containers built with nerdctl are not available in Kubernetes by default.
To build a container that is available in Kubernetes you must specify the k8s.io namespace
# -n specifies the k8s.io namespace
nerdctl -n k8s.io build . -f containerfile -t app:0.0.1
# the container is visible inside Kubernetes
kubectl create deployment quick-test --image=app:0.0.1
Linux distributes system resources using control groups (cgroup) which the kernel.org defines as
cgroup is a mechanism to organize processes hierarchically and distribute system resources along the hierarchy in a controlled and configurable manner. [1]
There are currently two versions of cgroup in use today and due to historical and compatibility reasons version 1 and version 2 of cgroups can coexist as long as there are no overlaps between which controllers are being managed.
The main, but not only, difference between cgroup version 1 and version 2 is that version 1 has a mount for each controller while version 2 unifies all the active controllers under a single mount point. This is obviously a very simplified explanation. Please see the official kernel documentation for more details on the two versions [2][3].
They typical mount point for both versions of cgroup is /sys/fs/cgroup. This is not a hard requirement and can be different depending on the distro. For instance Alpine Linux with OpenRC in hybrid mode will mount cgroup version 1 at /sys/fs/cgroup and version 2 at /sys/fs/cgroup/unified.
This table will assume that the cgroup root path is /sys/fs/cgroup and will use relative paths based on that. Adjust the relative paths based on your environment.
| resource | cgroup v1 | cgroup v2 |
|---|---|---|
| available memory | ./memory/memory.limit_in_bytes | ./memory.max |
| assigned cpu cores | ./cpuset/cpuset.effective_cpus | ./cpuset.effective.cpus |
| cpu bandwidth | ./cpu/cpu.cfs_quota_us | ./cpu.max |
| cpu period | ./cpu/cpu.cfs_period_us | ./cpu.max |
Refer to the documentation for the format for each file.
To determine which cgroup your application belongs to you can reference /proc/self/cgroup which will list all the cgroup that your process belongs to. Depending on the environment you may also need to map your cgroup to the actual mount point by inspecting /proc/self/mountinfo. This is especially true if running inside a container where the cgroup may refer to the path on the host and may not be accurate when viewed inside the container.
How many cores are on my system?
This is a seemingly simple question. We’d like to use the number of available processors to determine how many jobs we can safely run in parallel. Linux provides various ways to fetch the number of available processors including:
> nproc
32
> lscpu | grep ^CPU\(s\)\: | awk '{print $2}'
32
> grep --count "processor" /proc/cpuinfo
32
I’ve been thinking about ways to be more active in my Rust exploration and I think that I’ve settled on the idea of Prompts.
Prompts are project-based learning experiments where I will explore Rust concepts, crates, or tools. The prompts should be narrow enough in scope that they can be completed in about a week. While only spending at most an hour a day.
The prompts will include
More importantly prompts should not be
Complex topics should be the subject of their own prompt and broken down appropriately so that they may fit into the above criteria.
The NSA is officially recommending that software developers and operators migrate away from C and C++ to memory-safe languages like Rust, Go, Swift, and others.
The article cites Google and Microsoft, who state that 70 percent of their vulnerabilities can be attributed to software memory issues.
Rust 1.65.0 was released on November 3rd 2022.
As always Rust can be updated by running
rustup upgrade stable
Rust 1.64.0 was released on September 22nd 2022.
As always Rust can be updated by running
rustup upgrade stable