Kernel Watch
Jon Masters summarises the latest happenings in the Linux kernel, so you don’t have to.
Linus Torvalds announced Linux 5.7rc1 (release candidate 1) and with it the closure of the “merge window” (period of time during which disruptive changes are allowed) for what will hopefully be Linux 5.7 in time for the summer. Many new features were merged into this release, among them low-level hardware optimisations such as “split-lock” detection on x86, scheduler improvements that will enhance performance particularly on laptops, and a new Microsoft EXFAT filesystem driver contributed by Samsung that has Microsoft endorsement.
Just a couple of weeks earlier, Linus had announced the final 5.6 release, and had accompanied it with a note about the ongoing pandemic. He said that his “daughter laughed at me and called me a social distancing champ” – in reference to the fact that he usually works from home and doesn’t get out all that much even in more normal times.
Split-lock detection
Modern computers are formed from multicore designs in which many individual processor cores run tasks (processes) at the same time. Sometimes they’re operating on different data, but many times they share data. When this happens, great architectural pains are taken to ensure that each “observer” has the same view of the shared memory. This is known as “cache coherence” because it’s implemented by means of a special hardware protocol that synchronises updates to fast core cache memories.
Caches are relatively small memories that keep copies of recently used data. Their unit of operation is a “line”: typically 64 bytes in size (on nearly all Intel systems). If a piece of data located anywhere in memory is accessed or modified by a core, it’ll have the line that encloses it within its cache. A common example of shared memory is a lock. This is a few bytes representing a value that indicates ownership over a larger data structure or other associated resources.
Normally, locks are acquired and released by kernel code whenever it needs to gain brief exclusive use of some resource. The lock protects the updates from being corrupted by simultaneous updates from other cores since those will also check the lock variable before proceeding. Updates to the lock variable utilise special processor “atomic” instructions that will read the lock, update it, and store the update as a single operation.
A problem exists when a lock variable is poorly placed in memory in such a way that it straddles two cache lines. Such a situation is never allowed on most architectures, but it is allowed by x86. Unfortunately, the “LOCK” mechanism used on x86 for atomic updates to a single memory location requires special handling for cache line crossing updates, resulting in a brief (but very expensive) system-wide slowdown. Recent chips include an ability to check for split-locks and flag them for fixing, as enabled by Linux 5.7.