Hacker News new | past | comments | ask | show | jobs | submit login

     My understanding of the parent comment was that disabling
     IRQs would be used to prevent a thread from being scheduled
     out in the middle of an operation
1. The scheduler already respects this. It won't suspend during the body of a function. Only at entry/exit.

2. `chrt --sched-deadline X` can ensure your thread will run for `X`ns without interruption (higher priority then all other tasks). And ensure you always get the same time budget consistently. [1] [2] [3]

3. The original goal of decoding audio can mostly be handled with DEADLINE + setting CPU affinity + masking interrupts on that CPU. Modifying IRQ Masks dynamically hits a lot of internal locking, and hurts your cache coherency. Any gains in one process will reflect massively negatively on the entire system.

4. This really seems overkill. Deadline Scheduling will do 99% of it seems you/parent need/want. Basically your process cant be interrupted for NanoSeconds, and will run every NanoSeconds I suggest:

     chrt --sched-deadline [TIME_BETWEEN_RUNS_NS] --sched-runtime [TIME_WILL_RUN_NS] -p [PID]
(I may have the Runtime/Time between backwards).

Most my experiencing is the Networking for HFT not audio decoding FYI.

[1] https://en.wikipedia.org/wiki/SCHED_DEADLINE

[2] http://man7.org/linux/man-pages/man1/chrt.1.html

[3] Consistently means as close to absolutely prefect as possible. Your OS is a dynamic system so it'll be +/- a few NanoSeconds. Generally the delta is very small. Caches stall, RedBlack trees are re-balanced, work is stolen, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: