Linux (Kernel): BPF, Threading, MPK, systemd, and Mesa/LLVMpipe

-
Dumping kernel data structures with BPF
For as long as operating systems have had kernels, there has been a need to extract information from data structures stored within those kernels. Over the years, a wide range of approaches have been taken to make that information available. In current times, it has become natural to reach for BPF as the tool of choice for a variety of problems, and getting information from kernel data structures is no exception. There are two patches in circulation that take rather different approaches to using BPF to dump information from kernel data structures to user space.
When your editor first encountered paleolithic Unix systems, tools like ps would obtain their information by opening /dev/kmem and rooting around directly in the kernel's memory space. This approach had the advantage of requiring no direct kernel support, but there were also some disadvantages, including security issues, lack of atomicity in the collection of complex data, and occasionally returning random garbage. This behavior was perhaps acceptable in the early days, but contemporary users have become strangely less tolerant of it. So digging around in kernel memory has long since fallen out of favor.
In current Linux systems, this problem is solved with a collection of system calls and virtual files in /proc, sysfs, debugfs, and beyond. This approach works, but has some challenges of its own. The kernel must be modified whenever the information to be output changes, "debugging" information in debugfs ends up being needed for normal system operations (where debugfs should not be enabled), and changes can be hard to make without breaking existing applications. So there is a natural desire for something more flexible and adaptable.
-
Controlling realtime priorities in kernel threads
The realtime scheduler classes are intended to allow a developer to state which tasks have the highest priorities with the assurance that, at any given time, the highest-priority task will have unimpeded access to the CPU. The kernel itself carries out a number of tasks that have tight time constraints, so it is natural to want to assign realtime priorities to kernel threads carrying out those tasks. But, as Peter Zijlstra argues in a new patch set, it makes little sense for the kernel to be assigning such priorities; to put an end to that practice, he is proposing to take away most of the kernel's ability to prioritize its own threads.
In the classic realtime model, there are two scheduling classes: SCHED_FIFO and SCHED_RR. Processes in either class have a simple integer priority. SCHED_FIFO processes run until they voluntarily give up the CPU, with the highest-priority process going first. SCHED_RR, instead, rotates through all runnable processes at the highest priority level, giving each a fixed time slice. In either class, processes with a lower realtime priority will be completely blocked until all higher-priority processes are blocked, and processes in either class will, regardless of priority level, run ahead of normal, non-realtime work in the SCHED_NORMAL class.
The kernel pushes a large (and increasing) amount of work out into kernel threads, which are special processes running within the kernel's address space. This is done to allow that work to happen independently of any other thread of execution, under the control of the system scheduler. Most kernel threads run in the SCHED_NORMAL class and must contend with ordinary user-space processes for CPU time. Others, though, are deemed special enough that they should run ahead of user-space work; one way to make that happen is to put those threads into the SCHED_FIFO class.
But then a question arises: which priority should any given thread have? Answering that question requires judging the importance of a given thread relative to all of the other threads running at realtime priority — and relative to any user-space realtime work as well. That is going to be a difficult question to answer, even if the answer turns out to be the same for every system and workload, which seems unlikely. In general, kernel developers don't even try; they just pick something.
-
New Linux Patches Confirm Next-Gen EPYC "Milan" CPUs To Support MPK
Recently we noted the latest revision to AMD's Programmer Reference Manual points to PCID and MPK/PKEY support coming on future CPUs. New Linux patches now confirm that the MPK support is on the way with next-gen EPYC processors.
The Memory Protection Key (PKE) support has been supported by Intel processors since Xeon Skylake and allow for page-based memory protections with the RDPKRU and WRPKRU instructions. As noted in the PRM, the feature "provides a way for applications to impose page-based data access protections (read/write, read-only or no access), without requiring modification of page tables and subsequent TLB invalidations when the application changes protection domains."
-
systemd, 10 years later: a historical and technical retrospective
The end of this massive article posits a very interesting question. What init system does Chrome OS use? And Android? Do you know, without looking it up? Probably not.
What does that tell you?
-
Mesa's LLVMpipe Driver Adds 4x MSAA Support
David Airlie's "multi-sample support extravaganza" for the LLVMpipe software driver has been merged into Mesa 20.2-devel.
This big set of patches for LLVMpipe enables working 4x multi-sample anti-aliasing and includes window system multi-sampling and support for the OpenGL extensions of EXT_framebuffer_multisample, ARB_texture_multisample, ARB_sample_shading, and ARM_shader_texture_image_samples.
Airlie noted in the merge request this support has been tested with the Piglit test cases as well as Unigine Heaven.
-

- Login or register to post comments
Printer-friendly version- 2363 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is released
After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release.
|
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future Tech
The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world.
Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility.
|
today's howtos
|








.svg_.png)
Content (where original) is available under CC-BY-SA, copyrighted by original author/s.

Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago