问题
I have been reading a few posts and articles regarding thread quanta (here, here and here). Apparently Windows allocate a fix number of CPU ticks for a thread quantum depending on the windows "mode" (server, or something else). However from the last link we can read:
(A thread quantum) between 10-200 clock ticks (i.e. 10-200 ms) under Linux, though some granularity is introduced in the calculation
Is there any way to compute the quantum length on Linux? Does that make any sense to compute it anyway? (since from my understanding threads can still be pre-empted, nothing forces a thread to run during the full duration of the quantum)
From a developer's perspective, I could see the interest in writing a program that could predict the running time of a program given its number of threads, and "what they do" (possibly removing all the testing to find the optimal number of threads would be kind of neat, although I am not sure it is the right approach)
回答1:
- On Linux, the default realtime quantum length constant is declared as RR_TIMESLICE, at least in 4.x kernels;
HZmust be defined while configuring the kernel. - The interval between pausing the thread whose quantum has expired and resuming it may depend on a lot of things like, say, load average.
- To be able to predict the running time at least with some degree of accuracy, give the target process realtime priority; realtime processes are scheduled following a round-robin algorithm, which is generally simpler and more predictable than the common Linux scheduling algo.
- To get the realtime quantum length, call sched_rr_get_interval().
来源：https://stackoverflow.com/questions/42899151/thread-quantum-how-to-compute-it