Support: add l2-orchestrator-standalone bench for the L2 submit path - #1903
Open
network4agent wants to merge 1 commit into
Open
Support: add l2-orchestrator-standalone bench for the L2 submit path#1903network4agent wants to merge 1 commit into
network4agent wants to merge 1 commit into
Conversation
Host-only bench and profile for the four lines that build an L2 task graph (runtime_maker.cpp:538-541). It needs no CANN, SDK or NPU because host_build_graph already runs this orchestrator on the host into an SM mirror and only H2Ds the populated image; the harness stops before the H2D, so the GM heap becomes a host allocation and the dlopen'd entry is linked in through the same framework_bind_runtime. - The engine is compiled in place out of ../src, not copied, so the bench measures the runtime of whatever revision it sits on and there is nothing to keep in sync. The 8 engine TUs are build_config.py's `host` target minus host/ (runtime_maker and its CANN dependencies); check_extraction.sh asserts that correspondence still holds and that every path CMake names resolves. The one engine-side file the package owns is src/host_shim/, which defines the 9 diagnostic symbols the AICPU binary would otherwise provide. - One payload, qwen3_dynamic_tensormap.h at QWEN3_SPMD_TIER=0, compiled unmodified as C through the esl_shim C ABI. The tier is pinned because it changes the DAG, and a task count without its tier is meaningless. - Profiling has four levels, none of which modifies engine source: driver brackets, a copied rt->ops table, and the engine's own per-STEP and TensorMap counters behind their existing build flags. Baseline for perf/hbg-orch is in reports/. Reading it requires the cold/warm split: STEP 5 looks like 65% of submit cost, but 95% of that is first touch of the SM mirror. Prefaulted, the bottleneck is STEP 3, the TensorMap lookup, at 73%. The cause is not table pressure -- 4002 inserts over 4096 buckets -- but same-address sub-views: 98.2% of walked entries share the probe's buffer.addr, which pto_tensormap.h:30-34 requires so byte-range overlap detection works at all. Bounding caveat: nothing is ever reclaimed here. There is no scheduler and no completion, so the ring's watermark reclaim never fires, the task window and heap must hold the whole graph, and the reclaim paths are never entered. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Host-only bench and profile for the four lines that build an L2 task graph
(
runtime_maker.cpp:538-541). Adds one new top-level directory,l2-orchestrator-standalone/(24 files), and changes no existing file.It needs no CANN, SDK or NPU:
host_build_graphalready runs this orchestratoron the host into an SM mirror and only H2Ds the populated image, so the harness
stops before the H2D, the GM heap becomes a host allocation, and the dlopen'd
entry is linked in through the same
framework_bind_runtime.It compiles the engine in place
There is no copy of the runtime in this package. The 8 engine TUs are
build_config.py'shosttarget minushost/(runtime_maker and its CANNdependencies), compiled straight out of
src/, so the bench measures theruntime of whatever revision it sits on and there is nothing to keep in sync.
scripts/check_extraction.shasserts that correspondence still holds and thatevery path
CMakeLists.txtnames resolves. The one engine-side file the packageowns is
src/host_shim/host_shim.cpp— the 9 diagnostic symbols the AICPUbinary would otherwise provide.
What it measures
One payload —
qwen3_dynamic_tensormap.hatQWEN3_SPMD_TIER=0, compiledunmodified as C through an esl_proxy C-ABI shim. 3096 kernel submits + 779
framework allocs = 3875 engine tasks. The tier is pinned because it changes the
DAG, and a task count quoted without its tier is meaningless.
Four profiling levels, none of which modifies engine source: driver
brackets, a copied
rt->opstable, and the engine's own per-STEP and TensorMapcounters behind their existing
SIMPLER_ORCH_PROFILING/SIMPLER_TENSORMAP_PROFILINGflags.Result on this branch (Kunpeng-920,
-O3, pinned)Reading it requires the cold/warm split. Cold, STEP 5 looks like 65% of submit
cost — but 95% of that is first touch of the SM mirror (39.8 MB of payload ring
at
--task-window=8192, and STEP 5 is merely the first writer of each slot).Prefaulted, the bottleneck is STEP 3, the TensorMap lookup, at 73%.
The cause is pinned to same-address sub-views rather than table pressure:
PTO2_TENSORMAP_NUM_BUCKETSis 4096 and this case makes only 4002 inserts, yetthe average walked chain is 13.4 — and 98.2% of walked entries share the
probe's
buffer.addr. That ispto_tensormap.h:30-34working as specified("Hash only by base_ptr… ALL sub-regions of the same base tensor MUST be in the
SAME hash bucket"), which is what makes byte-range overlap detection possible
at all. Reducing it means a secondary order on
start_offset, not a biggertable.
Full report, with a
file:linecitation for every measured quantity:reports/perf-report-perf-hbg-orch-qwen3-dyn.md.Caveat that bounds every number
Nothing is ever reclaimed: no scheduler, no completion, so the ring's watermark
reclaim never fires, the task window and heap must hold the whole graph, and the
reclaim paths are never entered. This measures the fast submit path only.
Verification
ctest4/4 (includes a prefault test asserting the graph size is unchanged)scripts/check_extraction.sh3/3, negative-tested against a broken include path-Wall -Wextralddshows no CANN