Originally posted by ms178
View Post
Announcement
Collapse
No announcement yet.
"Nest" Is An Interesting New Take On Linux Kernel Scheduling For Better CPU Performance
Collapse
X
-
Originally posted by V1tol View PostBORE is just patched CFS. None of the schedulers I know address this task assignment problems. They are mostly focused on efficiency of task prioritization but none of them actually take into account CPU cores.
Comment
-
Originally posted by birdie View PostI've been thinking about that for years, it's strange no one has raised the issue earlier. The Linux kernel is notorious for its penchant for juggling tasks between CPU cores for no reasons and that results in emptying whatever you had in L1/L2 caches prior and non-zero delays considering new CPU cores could be at their absolute lowest power settings when they are given a task to execute.
You could simply run:
7z b -mmt1
And see in top or any graphical process manager how the task is thrown between CPU cores.
[Granted, in a situation where you only have a handful of high workload threads, it would be "more" ideal if those were locked to their cores and the rest of the threads fought over the remaining ones. This does incur a latency hit though, and breaks down as the number of "high workload" threads increases.]
- Likes 11
Comment
-
Originally posted by gamerk2 View Post
There's a reason for that: You want to typically try and maximize thread uptime. Remember that there are literally hundreds if not thousands of threads fighting for CPU time; your thread of interest is going to get bumped at some point. You then have two options: Either wait for whoever bumped it to finish and reschedule on the same core, or bump someone else and reschedule on another core ASAP. That's why you see instances of high workload threads jumping between cores: The OS is trying to maximize their uptime, even if the core allocation is considered suboptimal.
[Granted, in a situation where you only have a handful of high workload threads, it would be "more" ideal if those were locked to their cores and the rest of the threads fought over the remaining ones. This does incur a latency hit though, and breaks down as the number of "high workload" threads increases.]
- Likes 1
Comment
-
I love this. I feel like the pursuit of pure performance sort of ignores practical realities in many real-world use cases. It's good to see some out-of-the-box thinking on such things.
Another scheduling thing I think might be handy is one that tries to keep threads on the core they were started on for longer to maximize cache benefits (and to start all processes on E cores), and a third would be for virtual guests that tries to keep a given process on a core, but also tries to spread out to use as many cores as possible simultaneously to take advantage of gang scheduling realities.
Comment
-
Originally posted by birdie View PostI've been thinking about that for years, it's strange no one has raised the issue earlier. The Linux kernel is notorious for its penchant for juggling tasks between CPU cores for no reasons and that results in emptying whatever you had in L1/L2 caches prior and non-zero delays considering new CPU cores could be at their absolute lowest power settings when they are given a task to execute.
Speaking of L1 - that's pretty much always going to be constantly cycled even if a thread were totally locked to a single core. It's too small to retain enough data, and it's meant to be small so it can be a lot faster.
Also as pointed out already, Windows has been doing the same thing for a long while.
- Likes 1
Comment
-
Originally posted by CochainComplex View PostBut this implies that the die layout has to be hardcoded for any cpu or at least any generation especially for the large server cpus...or maybe its given by staying in a numa node (for the lager ones)? maybe it is less problematic then i think
edit. There is another culprit aswell.
Lets imagine the scheduler chooses for performance the best high clockable core. Statistically one out of n is the best and will it always be. This would result in a potential overusage of one core and its neighbours. This will result in more thermal wearout on this particular core (and its neighbour.Last edited by bug77; 15 September 2022, 06:37 PM.
- Likes 4
Comment
-
Patches are here: https://gitlab.inria.fr/nest-public/...image_creation
Lets see if this works on something newer than kernel 5.9
- Likes 3
Comment
-
Originally posted by user1 View Post
Interesting.. What you described here is exactly the same as the behavior of the Windows scheduler someone described in another forum. In that forum I've even seen people calling the Windows scheduler "dumb", when it turns out the Linux scheduler actually works in a similar way.Last edited by F.Ultra; 15 September 2022, 10:52 AM.
- Likes 11
Comment
Comment