kvcache-ai/AgentENV

Fork 0

mirror of https://github.com/kvcache-ai/AgentENV.git synced 2026-11-05 01:17:36 +00:00

[GH-ISSUE #130] Support Linux kernel 6.6 by making ublk zero-copy optional #44

New issue

Closed

opened 2026-10-29 14:18:45 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-29 14:18:45 +00:00

Owner

Originally created by @zdy782 on GitHub (Aug 6, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/130

Affected component

Cross-cutting / other

Problem statement

As a user running AgentENV on a Linux 6.6 LTS host, I need AgentENV to install and run on kernel 6.6, because the current documented requirement of kernel 6.8+ blocks deployment even though the main missing capability appears to be limited to the ublk zero-copy path.

Use case

Single-node AgentENV deployments on hosts that ship kernel 6.6 by default, such as some Ubuntu/cloud/ARM images or enterprise LTS kernels. Expected scale is the same as existing single-node deployments; the main concern is being able to run the full runtime tier (template creation, OverlayBD/ublk rootfs, snapshots, pause/resume) without requiring a kernel upgrade.

Current behavior and workarounds

Today AgentENV requires Linux kernel 6.8+ in the README and deployment docs. The likely hard dependency is UBLK_F_AUTO_BUF_REG (io_uring sparse buffer table / ublk zero-copy), used by storage/ublk/src/ctrl.rs and storage/util/src/io_ring/uring.rs, with a UserBuffer fallback path already present in the codebase. There is no documented way to disable zero-copy and run on 6.6, so users either must upgrade the kernel or cannot use the runtime.

Desired behavior

Given a Linux 6.6 host with ublk available, when I configure AgentENV to disable ublk zero-copy, then I can start the server and run the normal runtime flow (template build, sandbox create, snapshot restore, pause/resume).

The configuration mode should be documented, including expected performance tradeoffs and any functionality that is unavailable without zero-copy.

Proposed approach

Make ublk zero-copy opt-in/fallback rather than implicitly required: detect support for UBLK_F_AUTO_BUF_REG, allow a config flag to disable it, and fall back to the existing UserBuffer path on kernels without the feature or when explicitly configured. Validate the reduced path on a 6.6 host with a smoke test covering OverlayBD/ublk rootfs, snapshot restore, and pause/resume.

Compatibility and operational impact

API/config changes: add a configuration option to disable ublk zero-copy (default behavior should remain unchanged on 6.8+).

Snapshot or storage format changes: none expected.

New host/runtime requirements: none; this lowers the kernel requirement for a supported reduced mode.

Upgrade and rollback considerations: existing 6.8+ deployments should be unaffected; 6.6 mode should be clearly labeled as a reduced-performance/non-zero-copy profile.

Alternatives considered

Keep requiring 6.8+ and document that 6.6 is unsupported. This is simpler but leaves a large group of LTS hosts out.

Backport/extend the kernel feature to 6.6 via patches. This is heavier and not under AgentENV's control.

Support 6.6 only as a build/install tier. This avoids the runtime question but does not solve the user problem.

Non-goals

Achieving performance parity between 6.6 (zero-copy disabled) and 6.8+.

Supporting all legacy kernels or arbitrary lower versions.

Backporting kernel changes.

Contribution

I can help test or review it

Pre-submission checklist

I searched existing issues and discussions and did not find a duplicate.
I described a concrete problem and use case, not only a proposed technology.
I understand that acceptance of the problem does not imply approval of a particular implementation.

Originally created by @zdy782 on GitHub (Aug 6, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/130 ### Affected component Cross-cutting / other ### Problem statement As a user running AgentENV on a Linux 6.6 LTS host, I need AgentENV to install and run on kernel 6.6, because the current documented requirement of kernel 6.8+ blocks deployment even though the main missing capability appears to be limited to the ublk zero-copy path. ### Use case Single-node AgentENV deployments on hosts that ship kernel 6.6 by default, such as some Ubuntu/cloud/ARM images or enterprise LTS kernels. Expected scale is the same as existing single-node deployments; the main concern is being able to run the full runtime tier (template creation, OverlayBD/ublk rootfs, snapshots, pause/resume) without requiring a kernel upgrade. ### Current behavior and workarounds Today AgentENV requires Linux kernel 6.8+ in the README and deployment docs. The likely hard dependency is UBLK_F_AUTO_BUF_REG (io_uring sparse buffer table / ublk zero-copy), used by storage/ublk/src/ctrl.rs and storage/util/src/io_ring/uring.rs, with a UserBuffer fallback path already present in the codebase. There is no documented way to disable zero-copy and run on 6.6, so users either must upgrade the kernel or cannot use the runtime. ### Desired behavior Given a Linux 6.6 host with ublk available, when I configure AgentENV to disable ublk zero-copy, then I can start the server and run the normal runtime flow (template build, sandbox create, snapshot restore, pause/resume). The configuration mode should be documented, including expected performance tradeoffs and any functionality that is unavailable without zero-copy. ### Proposed approach Make ublk zero-copy opt-in/fallback rather than implicitly required: detect support for UBLK_F_AUTO_BUF_REG, allow a config flag to disable it, and fall back to the existing UserBuffer path on kernels without the feature or when explicitly configured. Validate the reduced path on a 6.6 host with a smoke test covering OverlayBD/ublk rootfs, snapshot restore, and pause/resume. ### Compatibility and operational impact API/config changes: add a configuration option to disable ublk zero-copy (default behavior should remain unchanged on 6.8+). Snapshot or storage format changes: none expected. New host/runtime requirements: none; this lowers the kernel requirement for a supported reduced mode. Upgrade and rollback considerations: existing 6.8+ deployments should be unaffected; 6.6 mode should be clearly labeled as a reduced-performance/non-zero-copy profile. ### Alternatives considered Keep requiring 6.8+ and document that 6.6 is unsupported. This is simpler but leaves a large group of LTS hosts out. Backport/extend the kernel feature to 6.6 via patches. This is heavier and not under AgentENV's control. Support 6.6 only as a build/install tier. This avoids the runtime question but does not solve the user problem. ### Non-goals Achieving performance parity between 6.6 (zero-copy disabled) and 6.8+. Supporting all legacy kernels or arbitrary lower versions. Backporting kernel changes. ### Contribution I can help test or review it ### Pre-submission checklist - [x] I searched existing issues and discussions and did not find a duplicate. - [x] I described a concrete problem and use case, not only a proposed technology. - [x] I understand that acceptance of the problem does not imply approval of a particular implementation.

bsakaguchi

2026-10-29 14:18:45 +00:00

closed this issue
added the
enhancement
label

bsakaguchi commented

2026-10-29 14:18:46 +00:00

Author

Owner

@huang-jl commented on GitHub (Aug 15, 2026):

Currently, we do not use zero-copy feature of ublk, you can try to deploy and run agentenv on 6.6. Do you meet any errors?

@huang-jl commented on GitHub (Aug 15, 2026): Currently, we do not use zero-copy feature of ublk, you can try to deploy and run agentenv on 6.6. Do you meet any errors?

bsakaguchi commented

2026-10-29 14:18:46 +00:00

Author

Owner

@yingdi-shan commented on GitHub (Aug 19, 2026):

According to the community, AENV runs directly on kernel 6.6.

@yingdi-shan commented on GitHub (Aug 19, 2026): According to the community, AENV runs directly on kernel 6.6.

bsakaguchi commented

2026-10-29 14:18:46 +00:00

Author

Owner

@armBOY666 commented on GitHub (Aug 19, 2026):

Dear Teacher Shan,
Kernel version 6.6 meets the requirements for our use case. However, as noted in the documentation, ublk is not highly stable on this release. Have we run into any defects that could affect our current usage?

@armBOY666 commented on GitHub (Aug 19, 2026): Dear Teacher Shan, Kernel version 6.6 meets the requirements for our use case. However, as noted in the documentation, ublk is not highly stable on this release. Have we run into any defects that could affect our current usage?

bsakaguchi referenced this issue

2026-10-29 14:20:05 +00:00

[PR #44] [CLOSED] fix(orchestrator): resume sandboxes after recoverable pause failures #136