7 ms·

Please read Linus' discussion. He states (paraphrasing) - it's undefined because there's no real way (unless in a realtime scheduler) to find what to yield to

Please read Linus' discussion. He states (paraphrasing) - it's undefined because there's no real way (unless in a realtime scheduler) to find what to yield to without instigating complexity. The search itself is the quest that the kernel would rather not do at all. Step 3 is undefined and thus sched_yield itself is undefined.

dooglius 7y ago
Well, the scheduler has the same problem when the preemption timer goes off, doesn't it?
gwd 7y ago
GGP had a simple solution: "yield is the same as a preemption tick". I was trying to briefly explain what usually happens when you define things that way. I'm not advocating one thing or another.
jcranmer 7y ago
That is somewhat surprising to me. My idea of the canonical use case for yield is interprocess communication: process A sent a message to process B, and it wants to yield the remainder of its scheduling quantum to process B because process A has nothing left to do. Although maybe this use case is satisfied by something other than sched_yield.
- rowanG077 7y ago
  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.
- DougBTX 7y ago
  Yes, something else. Linus is pointing out that sched_yield doesn’t allow specifying where to yield control to, so it is a bad way to transfer control to a particular task.
- Filligree 7y ago
  The best way to do that is with a blocking write. You're sending the messages using a mechanism such as a pipe, right? Pipes have a small buffer. Once it's full, the caller will block, and the scheduler will know precisely what to schedule to unblock it.
pmoriarty 7y ago
"there's no real way (unless in a realtime scheduler) to find what to yield to without instigating complexity" What about just temporarily increasing the process' nice value? That should be simple to do, and the scheduler already knows how to yield to processes with lower nice values.

dooglius 7y ago

Well, the scheduler has the same problem when the preemption timer goes off, doesn't it?

gwd 7y ago

GGP had a simple solution: "yield is the same as a preemption tick". I was trying to briefly explain what usually happens when you define things that way. I'm not advocating one thing or another.

jcranmer 7y ago

That is somewhat surprising to me. My idea of the canonical use case for yield is interprocess communication: process A sent a message to process B, and it wants to yield the remainder of its scheduling quantum to process B because process A has nothing left to do. Although maybe this use case is satisfied by something other than sched_yield.

rowanG077 7y ago
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.
DougBTX 7y ago
Yes, something else. Linus is pointing out that sched_yield doesn’t allow specifying where to yield control to, so it is a bad way to transfer control to a particular task.
Filligree 7y ago
The best way to do that is with a blocking write. You're sending the messages using a mechanism such as a pipe, right? Pipes have a small buffer. Once it's full, the caller will block, and the scheduler will know precisely what to schedule to unblock it.

pmoriarty 7y ago

"there's no real way (unless in a realtime scheduler) to find what to yield to without instigating complexity" What about just temporarily increasing the process' nice value? That should be simple to do, and the scheduler already knows how to yield to processes with lower nice values.