Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

test_cpu_threadpool: the 100x dispatch ratio is calibrated on 20 cores and flakes on 4-vCPU CI runners

Đã đóng
  • Có gì không ổn?
#3,130 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
testing-qa

Hướng nghiên cứu

Bắt đầu trong tests/vt/test_cpu_threadpool.cpp tại trường hợp oversubscribed dispatch does not cost a scheduler timeslice và đọc chú thích hiệu chuẩn bên cạnh Threadpool::Run. Tái hiện tỷ lệ dispatch trên một runner 4 vCPU, sau đó chọn và xác thực một điều chỉnh hiệu chuẩn vẫn nhạy với lỗi scheduler-timeslice đã ghi nhận. Chạy CPU test job và xác nhận trường hợp này đạt trên các runner nhỏ mà không che giấu lỗi đó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Row: QUANT-GGUF-CPU-THREADPOOL

tests/vt/test_cpu_threadpool.cpp, case oversubscribed dispatch does not cost a scheduler timeslice, asserts ratio < 100.0 on ratio = median_dispatch_us(cores + 1) / median_dispatch_us(cores / 2).

Observed on CI (4-vCPU hosted runner)

build-test-cpu job 102683560829 (PR #3095, run 34416865779), tests/vt/test_cpu_threadpool.cpp:610:

MESSAGE: empty-op dispatch: 2 threads 0.421 us, 5 threads 42.75 us, ratio 101.544
ERROR: CHECK( ratio < 100.0 ) is NOT correct!

The arms are 2 and 5 threads, which proves the runner reported hardware_concurrency() == 4.

Why this reads as a calibration gap rather than a detected defect

  • The recorded defect signature in this test's own comment is an over arm of 2999-5996 us at 21 threads against 18-20 us fixed. Here the over arm is 42.75 us, roughly 70x below that signature, so the waiter was not spinning through a scheduler timeslice.
  • The comment's calibration ("Verified both ways on 20 cores") and its margin ("~30x below the defect and ~28x above the fixed behaviour") come from a 20-core box with arms 10 and 21. On a 4-vCPU runner the arms are 2 and 5 and the denominator measured 0.421 us, about 4x below the 1.68 us the same comment calibrates against, so the ratio is dominated by denominator noise.
  • std::thread::hardware_concurrency() is not reduced by CPU affinity on this glibc: taskset -c 0-3 <binary> still selects 24/49-thread arms, so the 4-vCPU geometry cannot be reproduced locally by pinning cores.
  • main's own build-test-cpu job 103074166342 passes the same test on the same runner class, so the check is marginal there rather than deterministically red.

Suggested fix (owner's call; changing an assertion needs its own spec)

Floor the denominator, for example over_us < std::max(100.0 * fits_us, <absolute floor>), or scale the threshold with cores, or skip the case below 8 cores. Any of these must keep the case able to fail for the defect it was written for.

Found while triaging an unrelated red check on PR #3095: that diff changes attention and embedding gating in src/vt/ops.cpp and never calls the measured path, which is Threadpool::Run with an empty body.

Ngôn ngữ chính
C++
Star
423
Fork
53
Merge trung bình
1 ngày 7 giờ
Pull request đã merge (30 ngày)
382

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của mudler/vllm.cpp

Tất cả issue của mudler/vllm.cpp

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.