lkml.org 
[lkml]   [2000]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Interesting analysis of linux kernel threading by IBM
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.169 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site