Skip to content

docs: state the io_uring 5.19 floor, the epoll 5.10 floor and the v1.6.0 stamp (do not merge before the tag) - #108

Draft
FumingPower3925 wants to merge 7 commits into
mainfrom
fix/docsrel-polish
Draft

FumingPower3925 wants to merge 7 commits into
mainfrom
fix/docsrel-polish

Conversation

@FumingPower3925

@FumingPower3925 FumingPower3925 commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Do not merge before the v1.6.0 tag. Two of the changes state the v1.6.0 release: introduction.md names the current release as v1.6.0 and the "currently" line in its Version bullet as 1.6.0. Until the tag, v1.5.11 is the latest release and those lines would be wrong. The orchestrator merges this at the tag. This PR is a draft and is not marked ready.

#N in this body means goceleris/celeris#N. The item numbers are the unticked - [ ] lines of goceleris/celeris#891, counted in order: 14 is the io_uring and epoll floor line (body line 16), 28 is the introduction stamp line (body line 33). The checklist issues stay open until the final verification pass.

What changed, per item

  • Item 14 (io_uring and epoll floors). The io_uring engine refuses every kernel before 5.19: celeris/internal/engine/iouring (New) builds no engine there, because the engine's cancels use the IORING_ASYNC_CANCEL flags that 5.19 added (celeris#682, #872). The floor is now 5.19 wherever io_uring is named: the celeris.IOUring rows in configuration.md and core-concepts.md, the engines table row and the "Linux 5.19+" sentence in engines.md, the performance.md row, the getting-started.md requirements row, introduction.md, and the index.astro io_uring card. The epoll floor is 5.10+, as the celeris README states it (README.md:335 and :464), in the getting-started.md requirements row, deployment.md (the epoll sentence) and the engines.md table cells for Epoll and Adaptive. The Adaptive floor is 5.10+ (README.md:336, :464); as reworded in review round 1, Adaptive uses io_uring only on a 6.1+ kernel that passes the startup probes (epoll below that). engines.md's tier table is reworked: High is 5.19+ (zero-copy send from 6.0, DEFER_TASKRUN from 6.1), Optional is 6.0+ and chosen only when the provided-buffers probe has failed, and Base is a 5.19+ fallback, used when the provided-buffers probe fails on a 5.19 kernel, when the kernel's feature bits do not match its version, or when CELERIS_MAX_IOURING_TIER=base caps the tier (celeris/internal/engine/iouring/tier.go (SelectTier), celeris/internal/probe/tier.go (determineTier)). The "A 5.12 kernel transparently uses the Base feature set" sentence is replaced: a kernel before 5.19 gets no io_uring engine; Adaptive runs epoll and an explicit IOUring engine returns the error.
  • Item 28 (introduction stamps). introduction.md:18 now reads v1.6.0 and :147 reads 1.6.0, both at the tag. Until then the stamp is v1.5.8/1.5.8.

Neighbours changed in the same functions

  • index.astro io_uring card body: "multishot accept/recv, provided buffer rings and zero-copy sendfile" became "multishot accept and, on 6.0 and later, zero-copy send". The io_uring engine has no sendfile (no sendfile in internal/engine/iouring); engines.md says epoll has it. Multishot receive with provided buffer rings is opt-in (CELERIS_IOURING_MULTISHOT_RECV=1), so it is no longer listed as a default feature.
  • deployment.md io_uring prerequisites bullet "Kernel": "LTS-stable io_uring floor" is replaced by the refusal and its reason (the cancels use the 5.19 flags).
  • deployment.md FAQ "Why is my server using epoll when I asked for io_uring?": the kernel line is now 5.19. The fallback is Adaptive's only: an explicit IOUring engine returns the error on a kernel below 5.19 or a blocked io_uring_setup (iouring.New, passed through by createEngine in engine_linux.go), and with a low RLIMIT_MEMLOCK it runs on fewer workers, down to one, and fails only when not even one ring fits (capWorkersToMemlock, review round 1).
  • deployment.md systemd comment: "otherwise the engine falls back to epoll" is now "otherwise Adaptive falls back to epoll; an explicit IOUring engine runs on fewer workers, and fails only when not even one ring fits".
  • engines.md "Std" section paragraph and the "Pre-5.10" row of the engine-choice table, and the "Force IOUring" bullet (≥5.10, ideally ≥5.19 or ≥6.0 is now 5.19 or later, ideally 6.0 or later).

Guard (failing first)

scripts/kernel-floor.test.ts is a bun test in the docs CI bun test step. It has five tests: every io_uring table row with a Linux floor states 5.19+ and no 5.10; no stale phrase (the exact old text, listed in the file) remains; each page carries its new floor sentence; the index.astro io_uring card reads Linux 5.19+ and the epoll card reads Linux 5.10+; and introduction.md names RELEASE on both lines.

  • Failing first: commit 803ead9 (guard only, on origin/main pages): 5 of 5 fail (logs/guard-control0-main.log, logs/control0-main-pages-final-test.log).
  • Control A, the docs pages reverted to origin/main and index.astro kept: the four docs tests fail, the index.astro test passes (logs/control-A-docs-main.log).
  • Control B, index.astro reverted and the docs pages kept: only the index.astro test fails (logs/control-B-index-main.log).
  • At 5cc7fa5: 5 of 5 pass (logs/r2-guard-after-edits.log), and the full bun test run is 34 pass, 0 fail (logs/r2-ci-test.log). The three control logs above were rerun at 87d121d with the pages pinned to 803ead9. Round 1 control: the guard with the new patterns against the 87d121d pages fails 2 of 5 (logs/r2-guard-before-edits.log).

Review round 1 (minors, all fixed in this PR)

  • introduction.md and engines.md no longer claim SQPOLL: no tier uses it (SQPollIdle() is 0 in highTier and optionalTier, celeris#377). deployment.md's CAP_SYS_NICE bullet now says it is not a prerequisite.
  • engines.md: a healthy 6.x kernel runs the High strategy; Optional only on 6.0+ with a failed provided-buffers probe; Base trigger narrowed from "a High feature probe" to the provided-buffers probe (a failed fixed-files or multishot-accept probe turns off that one feature and the tier stays High).
  • RLIMIT_MEMLOCK: the deployment.md systemd comment and FAQ and the engines.md notes (the "Force IOUring" bullet and the pitfall) now say an explicit IOUring engine runs on fewer workers and fails only when not even one ring fits; the kernel and blocked-syscall causes keep the "returns the error" wording. The deployment.md container section (both gates "transparently falls back", "does not crash") is scoped to Adaptive.
  • Adaptive: getting-started.md and engines.md say it uses io_uring only on a 6.1+ kernel that passes the startup probes. The same wording defect in celeris README.md:336 and :464 (and the SQPOLL tier comments) is appended as item 37 of celeris#891 (searched goceleris issues by mechanism first, no existing item).
  • Guard: new stale phrases (the old text) and new present patterns, failing first at 87d121d (2 of 5 tests fail: logs/r2-guard-before-edits.log), 5 of 5 pass at head (logs/r2-guard-after-edits.log). A one-line note beside RELEASE says a version bump must edit the constant too; the epoll 5.10 floor is named beside it.
  • Not changed: the epoll 5.10+ floor is still the README's figure, not enforced by code (see Open points); the orchestrator is to confirm it. The Base and Optional trigger conditions are from code reading (SelectTier, determineTier, the engine's probes), not from a kernel run.

Stale restatements grepped

git grep over the docs tree, on this branch, for 5\.10|3\.10|5\.12|1\.5\.8|5\.19, and for "pre-5." and "older kernel" phrases. The remaining 5.10 values are the epoll floor and the guard's own stale list. The remaining 1.5.8 is in scripts/build-data.ts:53, a historical note about v1.5.8 benchmark rigs, which is not a claim about the current release.

Open points (not blocking; the stated default is taken)

  • epoll 5.10+ is the README's figure, not a code floor. celeris/internal/probe/probe.go gates epoll at kernel 2.6, and no epoll code refuses a kernel below 5.10 that I found. Default taken: state 5.10+ as the README does. If the intended floor is lower, change the four places that say 5.10 for epoll: getting-started.md, deployment.md, engines.md (the Std paragraph) and index.astro. UNVERIFIED on a kernel before 5.10.
  • Release-gated text. The site already documents unreleased v1.6.0 behaviour (the "Since celeris v1.6.0" sentences on graceful-shutdown.md and others). Default taken: leave those; only the two stamps wait for the tag. The stamps are listed on celeris#649 (see the comment there).
  • The Base row's trigger conditions are from reading determineTier and the probe's tier topology, not from a run on a 5.19+ kernel with a failing High probe.

Verification

Commands and logs are under evidence/lanes-20261009/DOCSREL/logs/. Head of this PR: see the commit list. Commits: 803ead9 (guard, failing on origin/main), 8aa4aa1 (edits), 25310d1 (systemd comment), 87d121d (Adaptive floor and wording), e1a921e (review round 1 guard, failing first), 5cc7fa5 (review round 1 wording), 5768c40 (Optional row wording; guard 5 of 5 still pass, CI green).

  • Docs CI steps, in order, all pass at 5cc7fa5 (logs r2-ci-*.log; the ci-*.log files are the run at 87d121d): bun install --frozen-lockfile (r2-ci-install.log), bun run validate (0 errors, r2-ci-validate.log), bun run build (28 pages indexed, r2-ci-build.log), bun run check (0 errors, 0 warnings, 10 hints, r2-ci-check.log), bun test (34 pass, 0 fail, r2-ci-test.log).
  • The 20 text replacements were applied by edit-docsrel.py, each asserted unique before the write.

Not run, and owed: a rendered-page visual check of the changed tables, and a run on a real kernel (5.10 to 5.18, and 5.19) to show the refusal text and the Adaptive fallback that the new prose describes. The Cloudflare deploy runs the same bun run build. Nothing here was run on amd64 hardware; the docs have no amd64-specific claim.

Refs #891 item 14
Refs #891 item 28

…ease stamp

The guard fails on origin/main (5 of 5 tests) and passes once the pages
state the v1.6.0 floors. It is part of the docs bun test run.

Refs #891 item 14
Refs #891 item 28
…6.0 release stamp

The io_uring engine refuses every kernel before 5.19, so the 5.10 floor on
the io_uring rows and the engine tier table is replaced; Base is now a
5.19+ fallback. epoll is stated at 5.10+ as the celeris README gives it.
The introduction names v1.6.0 at the tag; this PR must not merge before it.

Refs #891 item 14
Refs #891 item 28
…mlock or kernel check fails

The systemd comment named the epoll fallback, which only Adaptive takes.

Refs #891 item 14
@FumingPower3925 FumingPower3925 added this to the v1.6.0 milestone Oct 20, 2026
@coderabbitai

coderabbitai Bot commented Oct 20, 2026 •

Copy link
Copy Markdown

Important

Review skipped

Ignore keyword(s) in the title.

⛔ Ignored keywords: 2
  • DO NOT MERGE
  • WIP

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration
  • Configuration used: Repository: goceleris/docs/.coderabbit.yaml
  • Review profile: ASSERTIVE
  • Plan: Advanced
  • Run ID: 7e555549-95b4-4746-857a-1892c3ad8e53

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

…the io_uring kernel wording

Refs #891 item 14
@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Oct 20, 2026 •

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Preview URL Updated (UTC)
✅ Deployment successful!
View logs
goceleris-docs 5768c40 Commit Preview URL

Branch Preview URL
Oct 20 2026, 08:50 AM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant