Read dispatch_reduce.cuh, kernel_reduce.cuh, agent_reduce.cuh,
tuning_reduce.cuh, and util_arch.cuh from cccl_upstream.
Key findings:
1. Reduce tile data is in REGISTERS, not SMEM. Our test_smem_safety
model (tile = threads * items * type_size) checks scale_mem_bound's
register-pressure cap, not actual SMEM usage. Real SMEM ≈ threads *
sizeof(AccumT), which is 2-8 KB, not 32-49 KB.
2. scale_mem_bound vs scale_reg_bound serve different purposes:
mem_bound allows items to 2x expand (for small types), reg_bound
does not. Both use 48KB as register-spill prevention, not SMEM.
3. Our float64 tuning (threads=384) may be too conservative. CCCL
SM100 uses threads=640 for float64 — this doesn't overflow SMEM
because SMEM is only used for BlockReduce communication.
4. paged_attn.py line 99 hardcodes use_v1=True, completely disabling
V2 partitioned attention. For 100K token sequences this is suboptimal.
5. _PARTITION_SIZE=512 is hardcoded, should be tunable via muh.
55b704c0e0