Linux has a set of events you can query to look at performance of … well lots of things. Its a generic mechanism. Here’s a quick peek at the set of values I can see if I look at an AltraMax running Fedora 36.Continue reading
Linux kernel work can call for you to test out a patch set that someone has posted to the Linux Kernel Mailing List (LKML). If the patch sets are sufficiently long enough, you want to apply them all together, and not have to down load them individually. I recently worked through this, and here’s how I got things to work.Continue reading
I’ve been looking in to PCIe+CXL. These are my notes.Continue reading
The systems I am working with have 80 or more cores in them. I’ve recently had to investigate processes around core start up. Here are my notes.Continue reading
ARM64 design defines features long before there is a CPU that can implement those features. Since the ARM ecosystem is so varied, there are many different CPU designs out there with different capabilities. A general purpose linux Kernel build put out by a major distribution has to work across a wide array of chips by a large nuymber of vendors. Thus, there is an enumeration of the capabilities inside the Kernel and mechnism for describing how to probe each of these capabilities.Continue reading
We have reason to believe that we should not be setting CONFIG_EFI_DISABLE_RUNTIME=y In our Kernel configs. I want to perform a controlled expereient booting two Kernel builds, one with this option set and one with it disabled. Since I have the option set, building that Kernel is trivial.
make olddefconfig make -j$(nproc) rpm-pkg
Now, to turn that option off, I could just edit the .config file. However, it is possible that there are other config options linked to that one, and there is logic to modify them together. I want to see what happens if I use make menuconfig to change the option to confirm (or deny) that only that option gets changed. But where do I find this option in the menu?Continue reading
I won’t go into checking out or building the Kernel, as that is covered elsewhere. Assuming you have a buildable Kernel, you can build the tests with:
make -C tools/testing/selftests
But you are probably going to see errors like this:
ksm_tests.c:7:10: fatal error: numa.h: No such file or directory 7 | #include <numa.h> | ^~~~~~~~ compilation terminated.
The userland test suites use several libraries and need headers to compile the tests that call those libraries. Here is the yum, line I ran to get the dependencies I needed for my system:
sudo yum install libmnl-devel fuse-devel numactl-devel libcap-ng-devel alsa-lib-devel
With those installed, the make line succeeded.
Running the test like this CRASHED THE SYSTEM. Don’t do this.
make -C tools/testing/selftests run_tests
A more sensible test to run is the example on the Docs page:
# make -C tools/testing/selftests TARGETS=ptrace run_tests make: Entering directory '/root/linux/tools/testing/selftests' make --no-builtin-rules ARCH=arm64 -C ../../.. headers_install make: Entering directory '/root/linux' INSTALL ./usr/include make: Leaving directory '/root/linux' make: Entering directory '/root/linux/tools/testing/selftests/ptrace' make: Nothing to be done for 'all'. make: Leaving directory '/root/linux/tools/testing/selftests/ptrace' make: Entering directory '/root/linux/tools/testing/selftests/ptrace' TAP version 13 1..3 # selftests: ptrace: get_syscall_info # TAP version 13 # 1..1 # # Starting 1 tests from 1 test cases. # # RUN global.get_syscall_info ... # # OK global.get_syscall_info # ok 1 global.get_syscall_info # # PASSED: 1 / 1 tests passed. # # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 ok 1 selftests: ptrace: get_syscall_info # selftests: ptrace: peeksiginfo # PASS ok 2 selftests: ptrace: peeksiginfo # selftests: ptrace: vmaccess # TAP version 13 # 1..2 # # Starting 2 tests from 1 test cases. # # RUN global.vmaccess ... # # OK global.vmaccess # ok 1 global.vmaccess # # RUN global.attach ... # # attach: Test terminated by timeout # # FAIL global.attach # not ok 2 global.attach # # FAILED: 1 / 2 tests passed. # # Totals: pass:1 fail:1 xfail:0 xpass:0 skip:0 error:0 not ok 3 selftests: ptrace: vmaccess # exit=1 make: Leaving directory '/root/linux/tools/testing/selftests/ptrace' make: Leaving directory '/root/linux/tools/testing/selftests'
Next up is to write my own stub test.
You can use the Kernel build system to make your own RPMs using the the target:
Back when machines only had one or two CPUs (still the case for embedded devices) the OS Kernel was responsible for making sure that the machine coule process more than one instruction “path” at a time. I started coding back on the Commodore 64, and there it was easy to lock up the machine: just run a program that does nothing. I’d have to look back at the Old Programmer’s Guide, but I am pretty sure that a program had to voluntarily give up the CPU if you wanted any form of multi-tasking.
The alternative is called “preemptive multitasking” where the hardware provides a mechanism that can call a controller function to switch tasks. The task running on the CPU is paused, the state is saved, and the controller function decides what to do next.Continue reading
The sys file system is used to expose Linux constructs to user space. One place we can see ACPI based information is in /sys/firmware/acpiContinue reading