Skip to content

[Story]: Instrument I/O concurrency and partition-sizing signals across cudf-polars, rapidsmpf, kvikio #23810

Description

@Matt711

Problem

Tuning cudf-polars' I/O and memory-admission settings today is mostly guesswork. max_concurrent_io_tasks (#23552) and target_partition_size (#23549) are what prompted this, but the same blind spot applies to num_py_executors, kvikio_nthreads, pinned memory, and any future auto-tuning work. We audited cudf-polars, rapidsmpf, and kvikio and found the same pattern in all three: the raw signal usually already exists somewhere in the C++ layer, but is discarded, folded into an aggregate that's too coarse, or never wired up. Most of this list is "turn on a light that's already wired," not new sensor design.

Goal: give sweeps, benchmark runs, and future tuning work a way to tell what's actually causing a result, instead of guessing.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    PerformancePerformance related issuecudf-polarsIssues specific to cudf-polars

    Type

    No type

    Projects

    Status
    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions