Messages in this thread | | | Date | Sat, 12 Jun 1999 02:13:59 +0200 (CEST) | From | Davide Libenzi <> | Subject | Re: More new schedule() results ... |
| |
>this is what i suspected. If we are switching 450 threads that also do >some real work then we are trashing the cache _badly_ already, so pure >scheduling costs will not matter at all. Most systems (even loaded >servers) have typically less than 5 runnable processes. So those systems >will see 15% scheduling slowdown. Some applications might use many threads >- for those cases your patch is a nice improvement.
Another couple of points.
1) Even with the two tasks sample the 15 % slodown is not evident because the switching rate is statistically low.
2) My algo use the _same_ _sematics_ used by the old one but do it faster.
Probably You know better then me how many time schedule() is called in a Linux workstation ( system calls ). Lowering the time the cpu execute schedule() is not as lowering user mode code because schedule() code is mostly interrupt protected. This means a low speed in acknoledging IRQ and hence a worse system response to events.
This is all,
Davide.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |