Process Niceness (Priority) Setting Has No Effect on Linux

Changing nice value of a process has no effect in Linux

Your multi-core CPU can happily run both the parent and the child simultaneously. As long as both can run, their relative priorities don't matter.

In order to see the effect of nice, you have to load your machine such that there's always a process ready and waiting to run. The easiest way would be making your test multithreaded. Spawn (after the fork) a few worker threads in both the parend and the child, make them all increment the counter (make it either atomic or thread local), and see what happens.

Niceness and priority processes on Linux system

The priority of a process in linux is dynamic: The longer it runs, the lower its priority will be. A process runs when its actually using the CPU - most processes on a typical Linux box just wait for I/O and thus do not count as running.

The priority is taken into account when there are more processes running than CPU cores available: Highest priority wins. But as the winning process looses its proirity over time, other processes will take over the CPU at some point.

nice and renice will add/remove some "points" from priority. A process which has a higher nice value will get lesser CPU time. Root can also set a negative nice value - the process gets more CPU time.

Example: There are two processes (1 and 2) calculating the halting problem and one CPU core in the system. Default is nice 0, so both processes get about half of the CPU time each. Now lets renice process 1 to value 10. Result: Process 2 gets a significant higher amount of cpu time as process 1.

Note: In modern desktops there is plenty CPU time available - they are fast these days. Unfortunately HDDs are still relativeley slow on random I/O, so even a nice process can generate enough I/O traffic to significantly slow down a system.

Does nice affect the priority of Java threads

Actually...Niceness is a property of the application according to POSIX.1. Here is a more detailed post. is nice() used to change the thread priority or the process priority?

Linux: setting process priority AND dynamically loading libraries

I have two solutions which do not involve modifying libc. Both solutions require us to replace the calls to sched_setscheduler() with a call to launch another process directly.

1. Install a file to /etc/sudoers.d/ with the following line:

   %users ALL=NOPASSWD: /usr/bin/chrt
   

   Then from our application launch sudo as a process with arguments chrt -f -p X Y where X is the configured priority and Y is the result of getpid().

2. Create a custom chrt with:

   cp $(which chrt) $(DESTDIR)/bin/chrt
   sudo setcap cap_sys_nice+ep $(DESTDIR)/bin/chrt
   sudo chmod 755 $(DESTDIR)/bin/chrt
   

   Then from our application launch chrt as a process with arguments -f -p X Y

Not sure which solution is better. Note this is effectively embedded (or at least purpose built) so I'm not too worried about the security exposure.

Python - decrease niceness value

Linux, by default, doesn't allow unprivileged users to decrease the nice value (i.e. increase the priority) of their processes, so that one user doesn't create a high-priority process to starve out other users. Python is simply forwarding the error the OS gives you as an exception.

The root user can increase the priority of processes, but running as root has other consequences.

is nice() used to change the thread priority or the process priority?

The pthreads man page says:

POSIX.1 also requires that threads share a range of other attributes
(i.e., these attributes are process-wide rather than per-thread):

[...]

• nice value (setpriority(2))

So, theoretically, the "niceness" value is global to the process and shared by all threads, and you should not be able to set a specific niceness for one or more individual threads.

However, the very same man page also says:

LinuxThreads

The notable features of this implementation are the following:

[...]

• Threads do not share a common nice value.

NPTL

[...]

NPTL still has a few non-conformances with POSIX.1:

• Threads do not share a common nice value.

So it turns out that both threading implementations on Linux (LinuxThreads and NPTL) actually violate POSIX.1, and you can set a specific niceness for one or more individual threads by passing a tid to setpriority() on these systems.

Does using setpriority() have any affect if my scheduling policy is SCHED_OTHER

The answer is no. The setpriority should not affect the process in this case. As per the documentation:

http://linux.die.net/man/3/setpriority

> Any processes or threads using SCHED_FIFO or SCHED_RR shall be unaffected by a call to setpriority(). This is not considered an error. A process which subsequently reverts to SCHED_OTHER need not have its priority affected by such a setpriority() call.

I'm sorry but reading carefuly the http://man7.org/linux/man-pages/man7/sched.7.html:

SCHED_OTHER: Default Linux time-sharing scheduling
SCHED_OTHER can be used at only static priority 0. SCHED_OTHER is
the standard Linux time-sharing scheduler that is intended for all
threads that do not require the special real-time mechanisms. The
thread to run is chosen from the static priority 0 list based on a
dynamic priority that is determined only inside this list. The
dynamic priority is based on the nice value (set by nice(2),
setpriority(2), or sched_setattr(2)) and increased for each time
quantum the thread is ready to run, but denied to run by the
scheduler. This ensures fair progress among all SCHED_OTHER threads.

Thus, the dynamic priority of the threads is affected by the call to setpriority and it should cause changes in the scheduling (depending on the new priority value being set in the call).

---

Related Topics