1
0

doc: format

This commit is contained in:
2026-05-28 23:22:37 +02:00
parent e54856dc00
commit 0abaa8414e
2 changed files with 11 additions and 4 deletions

View File

@@ -26,7 +26,7 @@ syslog(LOG_INFO, "Start logging silly led-controller"); // INFO level
The most difficult part was understanding the #gls("gpio", long: false) mapping between the physical pins and the #gls("sysfs", long: false) #gls("gpio", long: false) numbers. This mapping can be found in the #link("https://linux-sunxi.org/GPIO", [*sunxi driver*]) documentation, which describes the driver for the #gls("gpio", long: false) controller. The most difficult part was understanding the #gls("gpio", long: false) mapping between the physical pins and the #gls("sysfs", long: false) #gls("gpio", long: false) numbers. This mapping can be found in the #link("https://linux-sunxi.org/GPIO", [*sunxi driver*]) documentation, which describes the driver for the #gls("gpio", long: false) controller.
== Results == Results
We can demonstrate that the application works more efficiently than the provided silly #gls("led", long: false) controller: We demonstrate that the application works more efficiently than the provided silly #gls("led", long: false) controller:
#table( #table(
columns: (1fr, 1fr), columns: (1fr, 1fr),
@@ -46,4 +46,4 @@ We can demonstrate that the application works more efficiently than the provided
] ]
) )
We can see the difference between @fig-silly and @fig-epoll. One utilizes 100% of a CPU core, whereas the other does not. We see in @fig-silly, the silly #gls("led", long: false) controller use 100% of the #gls("cpu", long: false) in @fig-epoll we save CPU resources.

View File

@@ -44,6 +44,9 @@ static void catch_signal(int signal) {
} }
#pagebreak()
```c
static void install_catch_signal() static void install_catch_signal()
{ {
struct sigaction act = { struct sigaction act = {
@@ -227,7 +230,11 @@ With these prerequisites met, we can create two groups, one for each instance of
|> mkdir /sys/fs/cgroup/cpuset/low |> mkdir /sys/fs/cgroup/cpuset/low
|> echo 1 > /sys/fs/cgroup/cpuset/low/cpuset.cpus |> echo 1 > /sys/fs/cgroup/cpuset/low/cpuset.cpus
|> echo 0 > /sys/fs/cgroup/cpuset/low/cpuset.mems |> echo 0 > /sys/fs/cgroup/cpuset/low/cpuset.mems
```
#pagebreak()
```bash
# Create and allocate CPU for program "high" # Create and allocate CPU for program "high"
|> mkdir /sys/fs/cgroup/cpuset/high |> mkdir /sys/fs/cgroup/cpuset/high
|> echo 2,3 > /sys/fs/cgroup/cpuset/high/cpuset.cpus |> echo 2,3 > /sys/fs/cgroup/cpuset/high/cpuset.cpus
@@ -246,7 +253,7 @@ We can then open two shells and run the test program in each of them, while addi
As shown in @max-cpu, as expected, both processes in the "low" program are limited to #gls("cpu", long: false) core 1, while the "high" program uses #gls("cpu", long: false) cores 2 and 3 (one for each process). As shown in @max-cpu, as expected, both processes in the "low" program are limited to #gls("cpu", long: false) core 1, while the "high" program uses #gls("cpu", long: false) cores 2 and 3 (one for each process).
#figure( #figure(
image("max-cpu.png"), image("max-cpu.png", width: 90%),
caption: [CPU usage of the two programs with dedicated resources] caption: [CPU usage of the two programs with dedicated resources]
)<max-cpu> )<max-cpu>
@@ -268,6 +275,6 @@ After running the test program in each shell, we can observe in @shared-cpu that
#figure( #figure(
image("shared-cpu.png"), image("shared-cpu.png", width: 80%),
caption: [CPU usage of the two programs with shared resources] caption: [CPU usage of the two programs with shared resources]
)<shared-cpu> )<shared-cpu>