Summary
PTO2_RING_TASK_WINDOW / PTO2_RING_HEAP / PTO2_RING_DEP_POOL are read process-globally via std::getenv in bind_callable_to_runtime_impl() (src/{a2a3,a5}/runtime/tensormap_and_ringbuffer/host/runtime_maker.cpp:258-260). Today the only way to set them is SceneTestCase.RUNTIME_ENV, which _temporary_env() applies to os.environ for the whole run (simpler_setup/scene_test.py:310-325, applied at the L2 path :1037 and L3 path :1124).
This works when L2 dispatches a single L2 callable, but when an L3 orchestration submits multiple L2 tasks via Orchestrator.submit_next_level() (python/simpler/orchestrator.py:114-129), all of them inherit the same process env — there is no way to give each L2 its own ring sizing. CallConfig (block_dim, aicpu_thread_num, ...) carries no env/ring-size fields.
Request: extend the config interface so each L2 can carry its own ring configuration, e.g. an optional per-task env / ring-size override on CallConfig (and the corresponding per-case config knobs in scene_test CASES), so an L3 dispatching N heterogeneous L2s can size each ring independently:
RUNTIME_ENV = {
"PTO2_RING_TASK_WINDOW": "128",
"PTO2_RING_HEAP": "262144",
"PTO2_RING_DEP_POOL": "256",
}Motivation / Use Case
- An L3 orchestration that fans out several different L2 kernels in one launch: a large attention L2 needs a big heap and 128-task window, while small element-wise L2s only need defaults. Today everyone gets the max footprint, wasting device memory, or the global setting underprovisions the large L2 (failure modes documented in
MULTI_RING.md suggest raising the env vars).
- Sizing values are part of the per-callable contract, not process state; per-L2 config also removes the
os.environ mutation from the test harness.
Likely plumbing: add optional ring-size fields to CallConfig, serialize them in the task descriptor/mailbox to AICPU, and have bind_callable_to_runtime_impl() prefer per-task values over the global env fallback.
Related: #834 (global structured runtime config API — orthogonal: it covers how to set these values programmatically; this issue covers per-task granularity within one L3 dispatch)
Summary
PTO2_RING_TASK_WINDOW/PTO2_RING_HEAP/PTO2_RING_DEP_POOLare read process-globally viastd::getenvinbind_callable_to_runtime_impl()(src/{a2a3,a5}/runtime/tensormap_and_ringbuffer/host/runtime_maker.cpp:258-260). Today the only way to set them isSceneTestCase.RUNTIME_ENV, which_temporary_env()applies toos.environfor the whole run (simpler_setup/scene_test.py:310-325, applied at the L2 path :1037 and L3 path :1124).This works when L2 dispatches a single L2 callable, but when an L3 orchestration submits multiple L2 tasks via
Orchestrator.submit_next_level()(python/simpler/orchestrator.py:114-129), all of them inherit the same process env — there is no way to give each L2 its own ring sizing.CallConfig(block_dim, aicpu_thread_num, ...) carries no env/ring-size fields.Request: extend the config interface so each L2 can carry its own ring configuration, e.g. an optional per-task
env/ ring-size override onCallConfig(and the corresponding per-caseconfigknobs in scene_testCASES), so an L3 dispatching N heterogeneous L2s can size each ring independently:Motivation / Use Case
MULTI_RING.mdsuggest raising the env vars).os.environmutation from the test harness.Likely plumbing: add optional ring-size fields to
CallConfig, serialize them in the task descriptor/mailbox to AICPU, and havebind_callable_to_runtime_impl()prefer per-task values over the global env fallback.Related: #834 (global structured runtime config API — orthogonal: it covers how to set these values programmatically; this issue covers per-task granularity within one L3 dispatch)