55b704c0e0
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.