Messages in this thread | | | Subject | Re: Interesting analysis of linux kernel threading by IBM | Date | Thu, 20 Jan 2000 11:20:35 -0800 | From | Larry McVoy <> |
| |
There are a number of unsubstantiated statements in this message and I'd like to request that the various people who are claiming that these statements are true, please back them up. All we need is vmstat/ps/top output on machines with these sorts of loads. Benchmark machines do not count, only real workloads, please.
: > Hondreds of tasks is just not a typical (perhaps even realistic) : > workload. : : Yes it is. : : If you are running a webserver.
ps -ax outout please.
: Or a highly threaded application.
Highly threaded == highly stupid in 99.9% of all cases. Before wacking the kernel to support these apps, please describe an application which would be be smaller and faster if it were select based.
: Or a machine with a lot of users. (For example, a University unix server)
vmstat & ps -axf please.
: Or an ftp server. (Where is the Linux equivalent of FreeBSD's ftp.cdrom.com?)
I'm with you here. I'd like to see this too. But before we "fix" the scheduler, I'd also like to see a some evidence that the scheduler is the issue, and benchmark evidence is of marginal interest.
: It is really a question of "Where does Linux want to go?"
I know where I don't want it to go. I don't want it to go down the "my dick is bigger than your dick" marketing rathole which has lead all the other Unix vendors into pretty much destroying their own kernel source base. All in the name of the mighty benchmark.
: If it wants to be a high performance server, Linux needs a new scheduler.
If it wants to be a high performance server, we need to design it to be a high performance server. My challenge to all of the "scheduler must be fixed" people is this: how are your proposed fixes going to help get us to performance levels 1000x what we are at today? They obviously aren't. So instead of going after the microwins, how about going after the big wins? In the past, I've outlined a plan that can get Linux kicking everyone's butt on 2048 processor (or bigger) boxes. You may or may not like my ideas, but the goals are certainly better than what you are doing. You're just falling into the same trap that has buggered up all of the existing Unix kernels: ``we're at performance level X, let's hack the system into performance level 2X''. That isn't designing or architecting, that's hacking. And that path leads to a crap source base. Please look at the big picture.
: 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.
This is a completely unsubstatiated statement. OK, everyone, do this:
$ vmstat load free cach swap pgin pgou dk0 dk1 dk2 dk3 ipkt opkt int ctx usr sys idl 0.00 4.3 96.9 0.4 0 0 0 0 0 0 0 0 104 53 0 3 97
Those people with the load field higher than 10, please tell us what you are doing.
- 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/
| |