Do Linux JVMs actually implement Thread priorities?
Wrote a quick Java proggy to spawn 10 threads with each priority and calculate pi (4*atan(1) method) with BigDecimals 500,000 times each, join on each thread and report the elapsed time for run method. Yeah, prob’ly not the best example, but keeping it basic. I’m aware of Bug4813310 It is non-trivial to do in C, but can we assume that native priorities are never set on Linux JVMs?
$uname -r && grep bogomips /proc/cpuinfo 2.4.33.3 bogomips : 4312.26 $java -version 2>&1 |head -1 Java version "1.6.0_01" $javac T.java && java -Xmx32m -XX:+UseThreadPriorities T 1:3112 2:2636 3:2662 4:3118 5:2870 6:3319 7:3412 8:3304 9:3299 10:3069 Looks like not much of a deviation that one would expect! That was on a small virtual Linux machine. Maybe just Sun’s? We shall try IBM J9 VM:
1:4091 2:4142 3:3957 4:3905 5:3984 6:3985 7:4130 8:4055 9:3752 10:4071 The gross numbers look pretty good in comparison, but there is no scale to the numbers from a thread priority perspective. Let’s try 500k iterations on a 2.6 kernel with an older Sun JVM, one that is constantly loaded with load averages rarely below 7:
$uname -r && grep bogomips /proc/cpuinfo 2.6.9-67.ELsmp bogomips : 3992.93 bogomips : 3990.00 $java -version 2>&1 |head -1 java version "1.4.2_14" $javac T.java && java -Xmx32m -XX:+UseThreadPriorities T 1:63200 2:64388 3:62532 4:58529 5:62292 6:64872 7:64885 8:64584 9:61653 10:61575 Let’s try IBM’s J9 on a real slab just with 2.6 kernel and since a bigger system I’ll increase iterations to 2,000,000.
$uname -r && grep bogomips /proc/cpuinfo 2.6.9-78.ELsmp bogomips : 5989.03 bogomips : 5985.03 bogomips : 5985.01 bogomips : 5985.02 bogomips : 5984.99 bogomips : 5985.02 bogomips : 5984.99 bogomips : 5985.02 $java -Xmx32m T # this is the IBM J9 1:1718 2:1569 3:1989 4:1897 5:1839 6:1688 7:1634 8:1552 9:2027 10:1522 Some great times, but still no apparent thread/process priorities. Let’s try a Windows box. I know that Windows has a fairly aggressive thread priority scheme. Anything above normal anecdotaly consumes much more. As such, let’s move to 900,000 iterations in each thread:
C:\>java -version java version "1.6.0_11" C:\>java -Xmx32m T 1:12578 2:12625 3:11469 4:11453 5:10781 6:8937 7:10516 8:8406 9:9953 10:7391 Very much what we’re looking for, no? So Linux JVM’s apparently don’t have thread priority? I understand that you can’t really renice to a lower nice level in C, but I would assume JVM engineers would have figured out how to keep a low-niced dispatcher of sorts.
Тема 7: Планирование в Linux
В операционной системе Linux планирование основано на потоках, поскольку потоки реализованы в ядре. Различают три класса потоков:
1. Потоки реального времени, обслуживаемые по алгоритму FIFO
2. Потоки реального времени, обслуживаемые в порядке циклической очереди
3. Потоки разделения времени. Обслуживаемые по алгоритму FIFO потоки имеют наивысшие приоритеты и не могут вытесняться другими потоками, за исключением того же потока реального времени с более высоким приоритетом, перешедшего в состояние готовности.
Обслуживаемые в порядке циклической очереди потоки реального времени представляют собой то же самое, что и потоки реального времени FIFO, но с тем отличием, что они имеют квант времени и могут вытесняться по таймеру. Такой, находящийся в состоянии готовности, поток выполняется в течение кванта времени, после чего поток помещается в конец своей очереди. Рассмотренные классы имеют более высокий приоритет, чем потоки разделения времени. Потоки реального времени внутри системы Linuxпредставлены приоритетами от 0 до 99, причем 0 – самый высокий, 99 – самый низкий.
Третий класс потоков представлен приоритетами от 100 до 139, т.е. в системе Linux реализовано 140 приоритетов.
Квант времени – количество тиков таймера, в течение которых процесс может выполняться( ~1 мс.) Планировщик Linux использует ключевую структуру данных, которая называется очередь исполнения.Эта очередь связана с процессором системы и помимо прочей информации поддерживает два массива active и expired.
Поля active и expired являются указателем на массив из заголовков 140 списков.
Работы планировщика. Планировщик выбирает задачу из активного массива с самым высоким приоритетом. Если квант времени этой задачи истек, то она переносится в список закончивших функционирование (возможно с другим уровнем приоритета). Если задача блокируется (например, в ожидании события ввода-вывода) до истечения ее кванта времени, то после события она помещается обратно в исходный массив, а ее квант уменьшается на количество уже использованного времени. После полного истечения кванта времени она также будет помещена в массив закончивших функционирование. Когда ни в одном из активных массивов больше нет задач, то планировщик просто меняет указатели, чтобы закончившие функционирование массивы стали активными и наоборот. Разным уровням приоритета присваиваются различные кванты времени, больший квант времени присваивается большему приоритету. Существует понятие статического и динамического приоритета. Статический приоритет возникает при создании процесса (потока). Динамический приоритет изменяется во время работы процесса (потока) в соответствии с политикой планирования данной операционной системы. В системе Linux с каждым потоком связывается значение nice. По умолчанию оно равно 0, но может изменяться с помощью системного вызова nice (value) -20
Динамический приоритет используется в системе linux для того, чтобы:
1. Уделять большее внимание интерактивным потокам
2. Предотвращать излишний расход процессорного времени
Максимальное увеличение приоритета = -5, максимальное снижение приоритета = +5.
Планировщик поддерживает связанную с каждой задачей переменную sleep_avg. Когда задача просыпается, эта переменная получает приращение, а когда задача вытесняется или истекает ее квант, эта переменная уменьшается на соответствующее значение. Планировщик linux пересчитывает новый уровень приоритета при перемещении потока из списка активных в список закончивших функционирование.
Кроме того, планировщик имеет функциональные возможности в отношении многопроцессорных или многоядерных систем, например, с каждым процессором связывается своя очередь выполнения. Планировщик рассматривает только готовые к выполнению задачи, которые помещаются в соответствующие очереди выполнения.
Те задачи, которые не готовы к выполнению и ждут выполнения различных операций ввода-вывода, помещаются в структуру очередь ожидания. Такая очередь связана с каждым событием, которого могут дожидаться задачи. Заголовок очереди ожидания содержит указатель на связный список задач.
How to increase thread priority in pthreads?
I am using pthread in Linux. I would like to increase the thread priority by setting the parameters sched_param.priority . However, I could not find much info from the net regarding the range of the thread priority I could set, or about the description of the thread priority. Also, I would like to know about the relative thread priority as I would not want to set the thread priority to be too high and resulting the OS to halt. Could someone help me with this?
3 Answers 3
The default Linux scheduling policy is SCHED_OTHER , which have no priority choice but a nice level to tweak inside the policy.
You’ll have to change to another scheduling policy using function pthread_setschedparam (see also man sched_setscheduler )
‘Normal’ scheduling policies: (from sched_setscheduler(2) )
SCHED_OTHER the standard round-robin time-sharing policy; SCHED_BATCH for "batch" style execution of processes; and SCHED_IDLE for running very low priority background jobs. Real-time scheduling policies:
SCHED_FIFO a first-in, first-out policy; and SCHED_RR a round-robin policy. In your case maybe you can use SCHED_BATCH as this does not require root privileges.
Warning: wrong usage of real-time scheduling policies may hang your system. That’s why you need root privileges to do this kind of operation.
Just to be sure of what your machine is capable of, you can use chrt tool from util-linux package.
As an example:
$ chrt -m SCHED_OTHER min/max priority : 0/0 SCHED_FIFO min/max priority : 1/99 SCHED_RR min/max priority : 1/99 SCHED_BATCH min/max priority : 0/0 SCHED_IDLE min/max priority : 0/0 A way to waste less time (which I often use):
alias batchmake='time chrt --batch 0 make --silent' While staying with user privileges, this propels the make by 15% (in my case).
Edit: introducing nice , SCHED_BATCH , SCHED_IDLE and chrt tool. For accuracy ! 🙂
@Hasturkun: you’re right there is the nice tweak, as an advice for the scheduler (not a scheduler priority!). Thanks for accuracy !
you don’t actually need root privileges, just need to have the rlimits set so that the max prio you’re allowed to set is > 0
@Spudd86: of course, one can tweak the system file limits.conf (in /etc/security/ on FC) to increase Hard values and then use setrlimit() as a standard user. Among other cases, this is indispensable for real-time audio mixing. This point was missing, I’ll edit to fix.
that’s what I was referring to, yes. You can also raise your nice limit, which would seem to be what would be the appropriate answer to the question, since they don’t want to be able lock the machine.
The current answer from levif (recommending SCHED_BATCH) is not correct for the current NPTL thread implementation on Linux (you can check which implementation your kernel has by running ‘getconf GNU_LIBPTHREAD_VERSION’).
In today’s kernel only the Real Time Scheduling policies allow setting of sched_priority — it is always 0 for the non-RT policies (SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE). Your only choice for the non-RT policies is to set ‘nice’ values e.g. by setpriority(). There are not good specifications of the exact behavior to expect by setting ‘nice’ however, and at least in theory it could vary from kernel version to kernel version. For current Linux kernels ‘nice’ has a very strong effect similar to priority, so you can use it pretty much interchangeably. In order to increase how often your thread is scheduled, you want to lower your ‘nice’ value. This requires CAP_SYS_NICE capability (typically root, although not necessarily, see http://man7.org/linux/man-pages/man7/capabilities.7.html and http://man7.org/linux/man-pages/man3/cap_set_proc.3.html).
In fact SCHED_BATCH is designed for the opposite case to what the questioner requested: it is designed for CPU-intensive, long running jobs, that can live with lower priority. It tells the scheduler to slightly penalize wake-up priority for the threads.
Also to answer one of the earlier comments (I don’t yet have sufficient reputation to comment in response — some upvotes for this answer would help 🙂 ). Yes the bad news is that the POSIX.1 specification says that ‘nice’ affects processes, not individual threads. The good news is that the Linux thread implementations (both NPTL and the original Linux Threads) break the specification and allow it to affect individual threads. I find it amusing that this is often called out in the «BUGS» section of the man pages. I’d say the bug was in the POSIX.1 specification, which should have allowed this behavior, not in the implementations which were compelled to provide it in spite of the specification and did so knowingly and deliberately. In other words — not a bug.
Most of this is detailed on the sched(7) man page (which for some reason is not delivered on my Fedora 20 system): http://man7.org/linux/man-pages/man7/sched.7.html
If you really wanted to affect sched_priority you could look at the Real Time policies such as SCHED_RR).