Tiêu cực của quá trình chạy với ưu tiên thời gian thực?

Có bất kỳ nhược điểm nào của các quy trình đang chạy với mức độ ưu tiên theo thời gian thực ( chrt -f 99) không?

Giả thuyết của tôi là điều này kết hợp với một mối quan hệ sẽ đảm bảo rằng mọi quy trình trước khi thực hiện quy trình của tôi là tối thiểu và do đó, bất kỳ jitter nào (cụ thể là độ trễ mạng) sẽ được giảm thiểu - điều này sẽ không giúp ích cho độ trễ chung, nhưng tại thời điểm này tôi còn hơn quan tâm đến jitter.

(Hạt nhân: 2.6.16 / 3.0)

linux process real-time

— Nim
nguồn

Điều này có vẻ hữu ích cho bạn: Làm thế nào để giảm jitter cho Java?

— ire_and_curses

@ire_and_curses, hiện tại quá trình này chạy trên lõi bị cô lập của riêng nó (ít nhất là luồng xử lý chính), tuy nhiên các ngắt không được lên lịch trên cùng lõi đó (không thể thực hiện điều này vì có một số quy trình tương tự dựa trên cùng một giao diện mạng ), đây là nỗ lực cuối cùng. Tần suất APIC rất thú vị, tôi chưa gặp phải điều này trước đây.

— Nim

Nhược điểm ngay lập tức nhất của việc chạy một quy trình thời gian thực là quy trình có thể dễ dàng bỏ đói mọi quy trình khác trên hệ thống. Kết quả từ quan điểm của bạn sẽ là máy tính hoàn toàn không phản hồi với bàn phím, chuột và có thể là mạng, miễn là quá trình thời gian thực đang sử dụng CPU. Điều này có thể xảy ra nếu có sự cố xảy ra và quá trình đi vào một vòng lặp vô hạn hoặc thậm chí tạm thời nếu quá trình bắt đầu tính toán chạy dài mà không cần chờ đầu vào định kỳ. (Vì vậy, ví dụ: không chạy SETI @ home với ưu tiên thời gian thực.)

Một quy trình đơn luồng đơn trên CPU đa lõi ít có khả năng gây ra sự cố này vì có các lõi khác mà quy trình ưu tiên thấp hơn có thể sử dụng. Nhưng nếu quy trình đó tạo ra bất kỳ quy trình con nào, chúng sẽ thừa hưởng cùng mức ưu tiên thời gian thực, do đó mọi thứ có thể vượt khỏi tầm kiểm soát nếu bạn không cẩn thận.

Các sched_setscheduler(2)trang người đàn ông có lời khuyên tốt:

Do một vòng lặp vô hạn không chặn trong một quy trình được lên lịch theo SCHED_FIFO hoặc SCHED_RR sẽ chặn tất cả các quy trình có mức độ ưu tiên thấp hơn mãi mãi, nên một nhà phát triển phần mềm phải luôn có sẵn trên bàn điều khiển một lớp vỏ được ưu tiên tĩnh cao hơn ứng dụng được thử nghiệm. Điều này sẽ cho phép tiêu diệt khẩn cấp các ứng dụng thời gian thực đã được thử nghiệm mà không chặn hoặc chấm dứt như mong đợi. Xem thêm mô tả về giới hạn tài nguyên RLIMIT_RTTIME trong getrlimit (2).

Đó phải là một vỏ trên bảng điều khiển - không thuộc Xterm, trừ khi bạn muốn ưu tiên tất cả các ưu tiên thời gian thực của X.

— Đi lang thang
nguồn

Vâng - đây là vấn đề chính mà tôi dường như gặp phải. Đọc ngắn mã nhân để xác định tất cả các quy trình cần có mức độ ưu tiên cao hơn, tùy chọn duy nhất là bỏ đói tất cả các quy trình khác ngoài quy trình của tôi và sau đó di chuyển bất kỳ thứ gì yêu cầu bất kỳ hình thức io nào sang các lõi khác ... hmmm. ..

— Nim