Linux: fix thread priority #14252
Linux: fix thread priority #14252
Conversation
|
in order to compensate for not being able to use high priority in linux, i modified it to use high_prio: 0, stock_prio: 9, low_prio: 19 |
Utilities/Thread.cpp
Outdated
| @@ -3028,6 +3028,24 @@ void thread_ctrl::set_native_priority(int priority) | |||
| { | |||
| sig_log.error("SetThreadPriority() failed: %s", fmt::win_error{GetLastError(), nullptr}); | |||
| } | |||
| #elif defined(__linux__) | |||
| // available niceness for nonroot: 0~19 | |||
| int linuxprio = 9; | |||
There was a problem hiding this comment.
this means that threads with previous normal priority now have lower priority than normal...
I don't see the point in these changes.
It seems like your only issue is with non-root. Then why add all this weird low priority logic?
There was a problem hiding this comment.
It's important to note that the impact of niceness value is limited to threads within the same process group due to Linux autogrouping. When scheduled with other processes, the niceness value behaves the same as 0
There was a problem hiding this comment.
How does that relate to my comment?
There was a problem hiding this comment.
Im trying to imply that although threads with normal priority now has lower priority, that doesnt mean other processes with normal priority get to interfere with the game thread.
But other high priority threads(in this case rsx thread with niceness of 0) inside the rpcs3 group gets to interfere, which is the desired behavior.
There was a problem hiding this comment.
I think this approach is fine
Utilities/Thread.cpp
Outdated
| } | ||
|
|
||
| // nonroot cannot increase niceness value | ||
| if ((getpriority(PRIO_PROCESS, threadpid) < linuxprio) || (euid == 0)) |
There was a problem hiding this comment.
So, if a thread sets lower priority, it cannot increase it afterwards if it is non-root?
There was a problem hiding this comment.
This is a problem because, named_thread is recycled from a pool after use. So it would get stuck with lowered priority.
There was a problem hiding this comment.
yes. i noticed this by testing alot and game threads are stuck with low priority. im thinking maybe we only should allow priority changes for root user and disregard nonroots...
There was a problem hiding this comment.
Does this handle the case where a user might have the appropriate rights (limits.conf or CAP_SYS_NICE)?
|
Welp. Maybe we should specify priority at named_thread startup and make separate thread pools for each priority. |
|
Is this ready to be tested? or does it need a rebase? |
|
Threadpool has been removed, this needs updating. |
|
@hoholee12 needs updating due to the removal of thread pool, marked as draft in the meantime |
By default, unless specified, all userland processes run with the SCHED_OTHER scheduling policy, which only supports one priority value: 0. The original code currently does not work in setting priority for each thread AT ALL. However, we can implement an alternative method to change thread priorities using the niceness value, which can be used with the SCHED_OTHER policy.
Niceness value ranges from -20 (highest priority) to 19 (lowest priority). However, there are a few caveats to consider: