3 ms·

Why would it yield to process B and not one of the hundreds of other processes running?

deleted 7y ago
[deleted]
Dylan16807 7y ago
In the case of the benchmark, at any point in time there might be 2 background processes that aren't asleep. So let's look over our cores: 6 of them are churning through processes that do nothing but call sched_yield. Nothing has been waiting to run for more than 3 microseconds. 2 of them are doing real work, and the benchmark threads that happen to be on the same core have been waiting to run for most of a millisecond. If you're stuck, then B is one of the processes that has been waiting. So the obvious change would be to move threads around in sched_yield. Then B will get scheduled within microseconds.
- rowanG077 7y ago
  How is it possible that there are only 2 background processes? Any normal Linux system has hundreds maybe even thousands of processes running.
  - Dylan16807 7y ago
    Two processes that aren't asleep. What's your CPU use right now? I bet it's less than 200%. Or will be if you exclude your web browser. The typical background process is active far less than one percent of the time.
    - rowanG077 7y ago
      That doesn't matter that still doesn't guaranty yielding the thread will allow another specific process to run. Especially not if that process is soft locked to a different core.
      - Dylan16807 7y ago
        > That doesn't matter that still doesn't guaranty yielding the thread will allow another specific process to run. Right, but you would expect the "switch to another thread" function to eventually pick the one that's sitting there with a growing and growing time since it last got a chance to run. It would be easy to guarantee that if any thread has been waiting for at least x amount of time, then any context switch without long-waiting local threads will pick that thread. (If it's on the same NUMA node, at least.) But in the actual implementation that time can build up to a huge amount with no effect, even as thousands of yield calls go by. > Especially not if that process is soft locked to a different core. Yeah, that's the problem, it's getting locked to a core even though other cores are desperate for threads to run.

deleted 7y ago

[deleted]

In the case of the benchmark, at any point in time there might be 2 background processes that aren't asleep. So let's look over our cores: 6 of them are churning through processes that do nothing but call sched_yield. Nothing has been waiting to run for more than 3 microseconds. 2 of them are doing real work, and the benchmark threads that happen to be on the same core have been waiting to run for most of a millisecond. If you're stuck, then B is one of the processes that has been waiting. So the obvious change would be to move threads around in sched_yield. Then B will get scheduled within microseconds.

rowanG077 7y ago
How is it possible that there are only 2 background processes? Any normal Linux system has hundreds maybe even thousands of processes running.
- Dylan16807 7y ago
  Two processes that aren't asleep. What's your CPU use right now? I bet it's less than 200%. Or will be if you exclude your web browser. The typical background process is active far less than one percent of the time.
  - rowanG077 7y ago
    That doesn't matter that still doesn't guaranty yielding the thread will allow another specific process to run. Especially not if that process is soft locked to a different core.
    - Dylan16807 7y ago
      > That doesn't matter that still doesn't guaranty yielding the thread will allow another specific process to run. Right, but you would expect the "switch to another thread" function to eventually pick the one that's sitting there with a growing and growing time since it last got a chance to run. It would be easy to guarantee that if any thread has been waiting for at least x amount of time, then any context switch without long-waiting local threads will pick that thread. (If it's on the same NUMA node, at least.) But in the actual implementation that time can build up to a huge amount with no effect, even as thousands of yield calls go by. > Especially not if that process is soft locked to a different core. Yeah, that's the problem, it's getting locked to a core even though other cores are desperate for threads to run.