Exposing RWF_DONTCACHE and RWF_ATOMIC flags in the os module

Ideas
1

I’d like to discuss the general approach to exposing new Linux kernel flags in the os module, prompted by the closure of Add `RWF_ATOMIC` constant to `os` module · Issue #127921 · python/cpython · GitHub (which proposed adding RWF_ATOMIC).

The issue was closed on the grounds of usefulness. I think CPython should generally defer to the OS developers’ judgment here. These flags go through significant review before being added to the kernel’s stable ABI.

Use case

The motivation for RWF_DONTCACHE is documented in mm/filemap: add read support for RWF_DONTCACHE - wireguard-linux - WireGuard for the Linux kernel . The problem: when reading large amounts of data through buffered I/O, the page cache fills up and triggers aggressive kswapd reclaim. Performance degrades from ~155 MB/s to ~70-95 MB/s, with multiple kswapd threads consuming near 100% CPU.

With RWF_DONTCACHE, pages are pruned from cache after reading. This maintains consistent ~155 MB/s throughput with roughly half the CPU usage.

My own use case is scientific microscopy imaging, where datasets routinely exceed available RAM and are read sequentially for processing. This pattern (large sequential reads that won’t benefit from caching) is common across ML pipelines as well.

Precedent

CPython already exposes RWF_DSYNC, RWF_HIPRI, RWF_SYNC, and RWF_NOWAIT in the os module for use with preadv/pwritev. Adding RWF_DONTCACHE and RWF_ATOMIC follows the same pattern.

Current workaround

Without stdlib support, the alternative is calling preadv2 via ctypes/cffi and defining the constants manually.

With that in mind, would you accept a PR that exposes RWF_DONTCACHE (Linux 6.14+) and RWF_ATOMIC (Linux 6.13+)?

2

I was motivated to explore this after watching https://www.youtube.com/watch?v=i-mXdwPUwzQ.

I would have included this in the body but was limited by some linking rule.

3

Sorry, this was our spam detector seeing a first-time poster linking to YouTube, which is usually a pretty strong indication the post is spam.

2 Likes
4

os.RWF_DONTCACHE was already added to Python 3.15 by expose `RWF_DONTCACHE` constant · Issue #139090 · python/cpython · GitHub.

PR gh-127922 adding RWF_ATOMIC was rejected because:

it’s not even documented by Linux yet

RWF_ATOMIC is now documented in the pwritev2 manual page. So I suggest to propose again a PR adding RWF_ATOMIC. I would support such PR.

3 Likes
5

Wow I missed the DONT_CACHE addition. Very excited about that.

I opened a RWF_ATOMIC PR, thank you for the encouragement.

1 Like
6

It seems like a clear policy on how and when to adopt these constants would make sense, so that whether adding or rejecting a request to add, there’s just a document you can point to to say it is (or is not) time. If documentation is a blocker, this could encourage motivated Python users to improve Linux docs.

1 Like
7

The docs were only part of my concern in the original PR. At the time of GH-127922, CPython would have been basically the only project that used RWF_ATOMIC, and I didn’t think that was good for our low-maintenance policy. That’s no longer the case.

Anyways, I just merged GH-143475, so os.RWF_ATOMIC will be in Python 3.15.

3 Likes