5 ms·

sched_yield does seem like it should have a pretty obvious meaning: do whatever you would do if the preemption timer went off right now. Whether it's a good ide

sched_yield does seem like it should have a pretty obvious meaning: do whatever you would do if the preemption timer went off right now. Whether it's a good idea or not, I don't see why it's considered "undefined".

gwd 7y ago
I haven't read Linus' discussions, but often what happens when you take that approach is: 1. Scheduler looks through all the processes on the system, decides A is the one that should run right now 2. A decides it doesn't want to run, calls yield. 3. Scheduler looks again, thinks A is still the right one to run, and runs it again. That is, in most cases, if the scheduler thought there was a better process to run, it would already have been running.
- barkingcat 7y ago
  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.
  - 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.
mike_hock 7y ago
What's the postcondition of "whatever you do when the preemption timer goes off"? What's the observable side effect for the program?
- im3w1l 7y ago
  I think I would state it like this: Yielding is communication with the OS. And communication with the OS is observable.
- dooglius 7y ago
  Well, it's a hint (but then so is `nice`), so it doesn't have any strict postcondition. The meaning of the hint would be that the process won't make good use of CPU cycles at present, and it would be preferable to yield to any other processes now, rather than being preempted later when it are busy.

gwd 7y ago

I haven't read Linus' discussions, but often what happens when you take that approach is: 1. Scheduler looks through all the processes on the system, decides A is the one that should run right now 2. A decides it doesn't want to run, calls yield. 3. Scheduler looks again, thinks A is still the right one to run, and runs it again. That is, in most cases, if the scheduler thought there was a better process to run, it would already have been running.

barkingcat 7y ago
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.
- 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.

mike_hock 7y ago

What's the postcondition of "whatever you do when the preemption timer goes off"? What's the observable side effect for the program?

im3w1l 7y ago
I think I would state it like this: Yielding is communication with the OS. And communication with the OS is observable.
dooglius 7y ago
Well, it's a hint (but then so is `nice`), so it doesn't have any strict postcondition. The meaning of the hint would be that the process won't make good use of CPU cycles at present, and it would be preferable to yield to any other processes now, rather than being preempted later when it are busy.