lkml.org 
[lkml]   [2000]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Interesting analysis of linux kernel threading by IBM
The amount of time wasted on a bad scheduler is the following: 

O(Num of Times schedule is called * Number of running processes)

When I run SPECWeb96 tests here, I see both a large number of running
process and a huge number of context switches.

Here's a sample of the vmstat data:

vmstat -n 1

procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 2320 2058424 587520 1061464 0 0 0 0 5700 34 0 7 93
0 0 0 2320 2058424 587520 1061464 0 0 0 0 5706 26 0 7 93
18 0 0 2320 2073664 587776 1061464 0 0 0 1 19950 15612 2 69 28
20 0 0 2320 2073032 588032 1061464 0 0 0 0 11753 11261 3 95 2
22 0 0 2320 2072192 588224 1061464 0 0 0 1 8020 7516 3 96 1
23 0 0 2320 2071560 588480 1061464 0 0 0 0 8258 7419 3 96 1
22 0 0 2320 2071120 588480 1061464 0 0 0 0 10207 9682 3 96 1
24 0 0 2320 2070320 588864 1061464 0 0 0 1225 8267 7618 3 96 1
23 0 0 2320 2069448 589384 1061464 0 0 0 0 11220 9875 3 96 1
21 0 0 2320 2068680 589640 1061464 0 0 0 0 10280 9952 3 96 1
21 0 0 2320 2067936 589896 1061464 0 0 0 578 8317 7571 3 96 1
22 0 0 2320 2067336 590024 1061464 0 0 0 0 9641 7892 3 96 1
24 0 0 2320 2066936 590088 1061464 0 0 0 0 8680 7402 3 96 1
24 0 0 2320 2065752 590664 1061464 0 0 0 1095 11344 10920 3 95 1
23 0 0 2320 2065216 590920 1061464 0 0 0 0 8037 7108 3 95 1
...

Notice. 24 running process and ~7000 context switches.

That is a lot of overhead. Every second, 7000*24 goodnesses are calculated.
Not the (20*3) that a desktop system sees. This is a scalability issue.
A better scheduler means better scalability.

Don't tell me benchmark data is useless. Unless you can give me data
using a real system and where it's faults are, benchmark data is a we
have.

SPECWeb96 pushes Linux until it bleeds. I'm telling you where it
bleeds. You can fix it or bury your head in the sand. It might not
be what your system is seeing today, but it will be in the future.

Would you rather fix it now or wait until someone else how thrown down
the performance gauntelet?

--Phil

Compaq: High Performance Server Division/Benchmark Performance Engineering
---------------- Alpha, The Fastest Processor on Earth --------------------
Phillip.Ezolt@compaq.com |C|O|M|P|A|Q| ezolt@perf.zko.dec.com
------------------- See the results at www.spec.org -----------------------
On Fri, 21 Jan 2000, Horst von Brand wrote:

> Davide Libenzi <davidel@maticad.it>, David Lang <dlang@diginsite.com>, said:
> > On Thu, 20 Jan 2000, Horst von Brand wrote:
>
> [...]
>
> > > Hondreds of tasks is just not a typical (perhaps even realistic)
> > > workload.
>
> > Yes it is.
> >
> > If you are running a webserver.
>
> Hundreds of CGIs running at the same time? Wow. But there I'd split load
> among machines way before...
>
> > Or a highly threaded application.
>
> Higly stupid idea, typically.
>
> > Or a machine with a lot of users. (For example, a University unix server)
>
> I have such machines here (dozens of users, plus random services). Rarely
> gets to 10.
>
> > Or an ftp server. (Where is the Linux equivalent of FreeBSD's
> > ftp.cdrom.com?)
>
> Hundreds of people downloading at the same time is not the same as hundreds
> of running tasks...
>
> > It is really a question of "Where does Linux want to go?"
>
> Benchmarkland, or real-world useful system?
>
> > If it wants to be a high performance server, Linux needs a new
> > scheduler.
>
> Say which hard facts?
>
> > If it wants to be the most efficient desktop machine, then it doesn't
> > need it NOW. However, the average number of programs people are
> > running on their machine are increasing, not decreasing.
>
> Yes. I expert load average to be in the ones soon, not 0.1s anymore.
>
> > Linux's real penetration has been in the server market. Why not make
> > it the best server it can be?
>
> Nobody is saying we shouldn't do it. But before screwing around, _measure_
> where the real bottlenecks (for _real_ use, not benchmarks) are.
> --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>


-
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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site