Originally posted by birdie
View Post
According to the quote:
an unprivileged process can decrease the nice value of a
target process that has a suitable RLIMIT_NICE soft limit; see getrlimit(2) for details.
target process that has a suitable RLIMIT_NICE soft limit; see getrlimit(2) for details.
The problem here is the default value of RLIMIT_NICE.
It seems that distros set them to 0, which means that user cannot change it and that is the problem.
With it sets to 0, you indeed cannot change that.
Originally posted by birdie
View Post
That's off-topic.
Originally posted by birdie
View Post
Now this obviously can be very wrong, but IMO a better version would be put foreground to P cores only.
It's easy on windows because the whole GUI stuff is put into the kernel instead of running in the userspace, so windows don't need any userspace software nor do they care about permission, etc because the GUI is in kernel.
On linux, you would need to design a new mechanism with reasonable permission checking and a bit resistant to bad hinting.
As it turns out, hinting done wrong is more harmful than not hinting at all and the scheduler can get smarter all the time, so I'm not exactly sure which direction it would take.
Originally posted by birdie
View Post
So why don't you just relax a bit and let the software devs do their job?
Originally posted by birdie
View Post
The most recent effort I found is "Energy Aware Scheduling" https://www.kernel.org/doc/html/late...ed-energy.html
It seems that they were able to leverage heterogeneous core architectures by modifing Completely Fair Scheduler (CFS), by putting more demanding tasks to P-core.
It is not very difficult to do that after all, scheduler monitors the time a process has been running within a timeslice, number of syscalls issued within that timeslice and other statistics all the time so it has the information to do so.
It can already migrate tasks away from a core to put it to sleep, so IMHO it can also balance the tasks to put more demanding ones to P-cores.
Checking the how much of the timeslice is consumed by the process may as well served as a good heuristics.
The number of syscalls within the timeslice can be used to determine how IO-heavy that task is, could put IO-heavy tasks onto the E-cores as I/O is way slower than the CPU.
Comment