From 2b2f095c258dd7dbcacd3e6967137908df3deeaf Mon Sep 17 00:00:00 2001 From: Helldez <74499579+Helldez@users.noreply.github.com> Date: Sat, 29 Aug 2026 19:11:31 +0200 Subject: [PATCH] docs: correct the macOS platform status after F_NOCACHE and the CI job Three lines still described the state before #182 and #184. - README said macOS is not exercised by CI. It is now compile-checked on every pull request and release tag, alongside Windows. - benchmark-method told a Mac reader that o_direct is a no-op there, which would have them ignore the one field #182 made truthful. - The platform-caveat paragraph still said macOS does not bypass the page cache. limitations.md and community-benchmarks.md were already correct; these three were missed in the same pass. --- README.md | 9 +++++---- docs/benchmark-method.md | 7 ++++--- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index b33778a..0f75edf 100644 --- a/README.md +++ b/README.md @@ -398,12 +398,13 @@ The model must live on a real filesystem (on Android `/data/local/tmp/...`, not `--moe-stream` for the plain mmap baseline. The byte-identity gates (streamed == resident) run with `cd build && ctest --output-on-failure` (needs `python3` with the `gguf` package). -Platform status: Linux is exercised by CI (build + gates) and Windows is where the +Platform status: Linux is exercised by CI (build + gates), and Windows and macOS are +compile-checked there on every pull request and release tag. Windows is where the [desktop numbers](#desktop) were measured. On Windows, build with CMake directly (Visual Studio Build Tools); the script above is bash, and MSVC puts the binary in `build\cli\Release\bmoe-cli.exe`. -macOS builds from the same sources (the platform branches exist) but is not exercised by CI. It has -no O_DIRECT; a direct request is served with `F_NOCACHE` instead (uncached, but not alignment-constrained), -and `o_direct` in the telemetry reports what the open actually achieved. +macOS builds from the same sources and has no O_DIRECT; a direct request is served with `F_NOCACHE` +instead (uncached, but not alignment-constrained), and `o_direct` in the telemetry reports what the +open actually achieved. ### Android diff --git a/docs/benchmark-method.md b/docs/benchmark-method.md index 78441c2..a99c2f2 100644 --- a/docs/benchmark-method.md +++ b/docs/benchmark-method.md @@ -22,7 +22,8 @@ bmoe-cli -m MODEL.gguf --moe-stream --cache-mb auto --io-threads 4 -t 4 -n 256 \ - **Check `o_direct=1` before trusting anything.** On Android the app's external files dir under `/storage/emulated` is FUSE-backed: the `O_DIRECT` open succeeds but reads can return wrong data, so the engine falls back to buffered and you are no longer measuring the path this page assumes. - `/data/local/tmp` and `/sdcard/Download` are real filesystems. On macOS the flag is a no-op today + `/data/local/tmp` and `/sdcard/Download` are real filesystems. On macOS `o_direct=1` means + `F_NOCACHE` was applied, which is uncached but carries no alignment or DMA contract (see [limitations.md](limitations.md)). - **Report** `s/token`, the `compute + flash I/O` split from the `moe-stream:` line, and the `moe-cache:` hit rate. @@ -212,8 +213,8 @@ free-RAM-floor table alongside the throughput one. dev host, identical output. Too large for CI. The streamer works on Linux, macOS and Windows, but the throughput targets are stated for Android -and Linux on flash: Windows `VirtualAlloc` commit-per-slice is heavier, and macOS does not bypass -the page cache today ([limitations.md](limitations.md)). +and Linux on flash: Windows `VirtualAlloc` commit-per-slice is heavier, and macOS leaves the page +cache through `F_NOCACHE`, a caching hint rather than an I/O mode ([limitations.md](limitations.md)). ## Where the published numbers come from