Paul McKenney, a Linux kernel RCU maintainer, writes about parallel programming, memory models, RCU, and Rust in the kernel.
Commenters recommend his series on transactional memory and his posts on Rust and RCU, with discussion of how hard kernel patterns are in Rust.
> Given that DEC Alpha famously had difficulty with RCU, it is only reasonable to ask how Rust will do with it.
> Including some wild speculation about how Rust's ownership model might be generalized
I recommend starting with the latests post in the series and the conclusions(https://paulmck.livejournal.com/64209.html and https://paulmck.livejournal.com/65056.html).
From the snippets at the beginning, it looks like the author documented how they started learning about how to solve these problems in Rust, and it does not take too long until the comment section starts pointing the author at crossbeam-rs, GhostCell, etc. which only start appearing in the series in the last couple of sections.
Learning Rust by implementing a linked-list is pretty hard, but "Learning Rust by implementing RCU" has to be, by far, the hardest way to learn Rust that I know of. Kudos to the author for pushing through this so quickly and thoroguly. The posts are all excellent.
I wish the author would go a little bit more into crossbeam-rs. One thing the author does not consider, is that a safe Rust interface to RCU is essentially a "proof of correctness" for RCU, i.e., it proves that using RCU via that interface cannot introduce undefined behavior. (Or maybe more technically, the contracts on the correctness of unsafe code within the safe wrapper provide a potentially incorrect "proof" of this).
AFAIK no such correctness proof for the C APIs exists (there are a couple of linters that catch some…
> This means that using it for the core parts may be feasible sooner rather than later, no?
More like much later. There are several performance-critical patterns used in the Linux kernel that are difficult to express in unsafe Rust and impossible to express in safe Rust.
See https://paulmck.livejournal.com/62436.html and especially https://paulmck.livejournal.com/64209.html
I think promoting the use of Rust for driver code is an excellent compromise.
As an aside, I'd like to see Linux go further and move many of these drivers to user space. Now that we have io_uring, old performance-based arguments for keeping certain drivers in ring 0 hold less weight.
EDIT:
Paste this hacky snippet into your browser's console to save all of the links into your clipboard:
(() =>
{
let result = [...document.querySelectorAll('td a')]
.map((link) =>
link &&
!link.href.includes('ycombinator') &&
!link.href.includes('javascript:void')
? link.href
: ''
)
.filter(Boolean);
result = [...new Set(result)];
result.sort();
copy(result.join('\n\n'));
})();
Just to help, here's a compiled-list of all of the links shared here so…
I shared this perspective, but luckily my job is awesome and (in a routine 1:1!) Paul told me why it's less straightforward than I thought: https://paulmck.livejournal.com/62436.html
my takeaway was essentially that you get sweet perf wins from semantics that are hard to replicate with a type system that's also making really strong guarantees without making the code SUPER gross.
Here's a pretty good blog post that discusses how the memory models could interact: https://paulmck.livejournal.com/65341.html
My understanding is that it might not be entirely settled yet, and is still being discussed. That could explain why there isn't much solid documentation written yet
I highly recommend Paul McKenney's blog series on this topic:
http://paulmck.livejournal.com/tag/transactional%20memory%20everywhere