add more alternatives

Signed-off-by: machine424 <[email protected]>

Author: machine424

Diff for: proposals/2025-01-02_direct-io.md

@@ -35,7 +35,8 @@ achieved through direct I/O are welcome.
 
 In addition to the issues mentioned above, sometimes the page cache generated during writes is not
 used at all. For instance, once chunks are written during compaction, they are opened via
-`mmap`, which renders the page cache produced during writing redundant and useless.
+`mmap`, which may render the page cache produced during writing redundant (on `OpenBSD` e.g.) or/and
+useless.
 
 ## Goals
 
@@ -153,9 +154,23 @@ adverse effects on CPU or disk I/O were observed.
 
 ## Alternatives
 
-An alternative approach is to focus on enhancing user understanding of page cache behavior within
+- An alternative approach is to focus on enhancing user understanding of page cache behavior within
 Prometheus, helping them better interpret and adapt to it, without making any changes.
 
+- [@dgl](https://github.com/dgl) has proposed using page cache hints to help with unpredictable
+  memory reclaim:
+  ```
+  Using posix_fadvise with POSIX_FADV_DONTNEED could be an option if it doesn't make sense
+  to totally avoid the cache (there's also Linux specific memory management options like
+  MADV_COLD, which could help for some of the container concerns to optimise which memory
+  is reclaimed, although it wouldn't likely have as much user visible impact on the page cache).
+  ```
+
+- The work [work](https://lore.kernel.org/linux-fsdevel/[email protected]/T/#cluster-upstream-ci)
+  on introducing the `RWF_UNCACHED` flag for uncached buffered I/O has resumed, Provided no concessions
+  or major changes are made solely to implement direct I/O support, direct I/O integration can always
+  be challenged when `RWF_UNCACHED` is released and proven effective. 
+
 ## Action Plan
 
 * [ ] Implement the direct I/O writer and its utils and use it for chunks writing