Asthenia0412 commented on issue #20401: URL: https://github.com/apache/tvm/issues/20401#issuecomment-6181633447
Thanks for the very detailed diagnostic data — the launch config difference makes the root cause clear. ### Root cause hypothesis Looking at `general_reduction.py` lines 192-199: ``` loops = sch.get_loops(block_infos[-1].block_rv) bx = sch.fuse(*loops[:num_leading_s]) r_loop, tx = sch.split(loops[-1], [None, len_tx]) # Always splits reduction ``` The reduction loop is **always** split into a parallel dimension matching spatial output size + 256-thread serial remainder, regardless of reduction size. For a 4-element reduction (2x2 MaxPool), this produces 147456 blocks × 256 threads to process 4 elements. ### Proposed fix direction Add a reduction-size check **before** the split. If `product(reduction_loop_extents) < THRESHOLD` (e.g. THRESHOLD=len_tx=256), keep reduction serial within each thread instead of splitting into a parallel dimension. This matches the SERIAL path observation: "one output per thread, serial four-element reduction followed by Add". I'd like to work on this if the direction looks right. Questions: 1. Does this threshold approach sound reasonable? 2. Should the fix target `GeneralReduction` only, or also `reduction.py`? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
