Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: Interesting analysis of linux kernel threading by IBM | Date | 21 Jan 2000 11:43:39 -0800 |
| |
In article <Pine.LNX.4.21.0001201818410.148-100000@dlang.diginsite.com>, David Lang <dlang@diginsite.com> wrote: >Shortly before I went and purchased $10,000 encryption co-processors for >my SSL web servers it was not unusual to see a 5 min loadave of 30-50 (and >one time I saw it go up to 144!!). This was on AIX quad 233 2G ram RS/6000 >servers, after I got the encryption co-processors the loadave dropped to >5-10
Ok, before this gets out of hand, let me just clarify:
- under loads like the above, scheduling speeds MEANS ABSOLUTELY NOTHING.
Nada. Zilch. Zero.
You aren't spending any time scheduling - you're spending all the time COMPUTING. The high load is because you're compute-bound, and you probably end up scheduling maybe a few hundred times a second. If that.
With a default timeslice in the 10-200 millisecond range (Linux defaults to 200ms, and that's probably too dang long), compute-active processes aren't really much an issue.
Basically, the situation where you have BOTH - large number of runnable processes AND - lots of scheduling activity
are very rare indeed. They are rare even in threaded code, unless that threaded code has a lot of synchronization points and a lot of synchronous inter-thread communication.
The IBM numbers are very interesting. The cache-line optimization is an obvious performance advantage, and has been incorporated into the recent kernels. But I think some people think that this is a common problem, and think that "load average" automatically equals scheduling. It isn't, and it doesn't.
Linus
- 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/
| |