# Up requirement from 2.6.24+ to Linux 4.18 - for restartable sequences?

**URL:** <https://discourse.julialang.org/t/up-requirement-from-2-6-24-to-linux-4-18-for-restartable-sequences/138685>\
**Category:** Internals & Design\
**Created:** [August 8, 2026, 2:09pm UTC](https://discourse.julialang.org/t/up-requirement-from-2-6-24-to-linux-4-18-for-restartable-sequences/138685 "2026-08-08T14:09:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 8, 2026, 2:09pm UTC](https://discourse.julialang.org/t/up-requirement-from-2-6-24-to-linux-4-18-for-restartable-sequences/138685/1 "2026-08-08T14:09:51Z")

</div>

Linux kernel 4.18 was officially released on August 12, 2018, already 8 years old EDIT: that was 4.8: ~~October 2, 2016, soon a decade old~~ , but the 4.18 Linux kernel, and older, are EOLed anyway already. After this year 6.1 will be latest supported.

[https://justine.lol/rseq/](https://justine.lol/rseq/)

> The best kept secret at the frontier of system programming right now is the Linux 4.18+ (c. 2018) concept of restartable sequences or rseq for short. They allow you to create thread-safe data structures without locks or atomics which scale to microprocessors with many cores.
> 
> It’s currently only possible to use rseq on Linux using handwritten assembly code. However I believe in the future, all operating systems will .. and all data structure libraries will be rewritten to use them.
> 
> So far the only software I’ve seen using rseq is tcmalloc, jemalloc, glibc, and cosmopolitan. That’s destined to change now that microprocessors with 128 or even 192 cores are becoming inexpensive.
> 
> For example, .. 3x faster [up to] with 96 cores, rseq makes my `malloc()` **43x faster** (versus using that same `sched_getcpu()` mutex sharding technique)
> 
> System programmers who don’t have a workstation like the ones above are going to be left behind like a dinosaur, with no opportunity to pluck the low hanging fruit of 10x performance optimizations. For example, I wouldn’t have been able to pull off the [speedups I made to matrix multiplication](https://justine.lol/matmul/) last year if I hadn’t splurged on a 96 core CPU  
> ..  
> If we compare rseq to a truly naïve solution, such as using a glibc mutex to guard an increment operation, then we see that rseq can actually make things go a **million times faster** judging by CPU time consumption. It sounds like I’m joking, except I’m not, since

I’m not exactly sure why (assembly currently and) 4.8 needed, I suppose you could support older conditionally, bu why bother? You want same data structures to ideally also work on non-Linux, one reason. I note WSL2 supports Linux kernel 6.1 on Windows, so I guess works that way, and oldest I found was [linux-msft-wsl-5.10.74.3](https://github.com/microsoft/WSL2-Linux-Kernel/releases/tag/linux-msft-wsl-5.10.74.3).

I’m not sure, I think this doesn’t need newer Linux (only multi-core);  
[https://justine.lol/matmul/](https://justine.lol/matmul/)

> The improvements are most dramatic for ARMv8.2+ (e.g. RPI 5), Intel (e.g. Alderlake), and AVX512 (e.g. Zen 4) computers. My kernels go 2x faster than MKL for matrices that fit in L2 cache, which makes them a work in progress, since the speedup works best for prompts having fewer than 1,000 tokens.