mirror of
https://github.com/rustfs/rustfs.git
synced 2026-07-29 09:38:59 +00:00
houseme
8fc637fb14
Each erasure block runs its Reed-Solomon encode through tokio::task::block_in_place on the multi-threaded runtime. That parks the worker and asks the scheduler to relocate other tasks, but the encode itself is only ~110µs per 1MiB block (p99 ~542µs) — the profiling in backlog#932 flagged the scheduling disturbance as comparable to the compute it guards. Call the encode closure inline on the multi-threaded runtime instead. The CurrentThread (and any other) flavor keeps spawn_blocking so the sole executor thread is never blocked and block_in_place's multi-thread-only requirement is respected. Applied to both ingest paths (encode_block / Vec and encode_block_bytes_mut / BytesMut); no change to encode output, quorum, shutdown, or error handling. Adds encode_works_on_multi_thread_runtime to cover the previously-untested multi-threaded arm for both ingest paths, asserting streaming and batched encode produce identical shard bytes. This is the low-risk, correctness-neutral item that backlog#932's adversarial verification recommended splitting out and doing first; the larger per-writer pipeline restructure it belongs to stays gated on a Linux multi-disk baseline. Refs: rustfs/backlog#932 (HP-11), rustfs/backlog#936 Co-authored-by: heihutu <heihutu@gmail.com>