Friday, January 21, 2000 1:53 AM
Larry McVoy <lm@bitmover.com> wrote :
Hi Larry,
> : I really don't understand Your position.
> : If we can have the same performance under "home" situations and be
prepared to
> : high load under either real world servers or benchmarks, why we don't do
it ?
>
> Because it is this line of reasoning that makes operating systems die.
> You are micro optimizing for a particular case. That's just plain BAD
> in an operating system. Special cases are BAD BAD BAD.
>
> And I've heard a million times "it's only 1%" or "I benchmarked it and it
> was the same". Of course it was only 1%, you only made one change. But
> there are 100s of engineers all saying "it's only 1%".
have You seen the current schedule() implementation ?
It's filled of goto to keep a linear CPU fast-path with blocks with lower
probability of execution
kept in tail of the function block.
To gain how in percent ?
My patch, IMVHO is more clear then goto jump-back solution, under normal
cases gives the same
results, while under I load gives much better performance.
> : Anyway I think benchmarks have their importance coz they drive servers
choice
> : decisions as long as stability issues.
>
> Look, I'm world wide famous for my benchmarking skill. I think benchmarks
> are important too but only if they represent a distilled version of
> an application, not a contrived situation. I can contrive a million
> different situations all of which are meaningless.
Remeber that not always strategic decisions are taken by cultured ( in a
computer science sense ) persons,
otherwise Apple would defeat MSDOS and OS2 would defeat Windows 3.0.
Anyway I prefer stability too, but if You can have both, why not ?
> : High threaded applications gives a better results given that are well
designed
> : with a fine resource locking system.
>
> Really? So what's the biggest application of that sort that you've
> designed or substantially implemented? Anything as big as the kernel?
> Me personally, I've worked on IRIX (scales to about 256 processors well,
> and to 2048 poorly) and Solaris (scales to mebbe 64 on a good day,
> usually more like 16-32). I've done in depth, multi year performance
> work on both of those platforms. I was sitting next door to Steve
> Kleiman when he was designing the SunOS multithreading architecture,
> which heavily influenced the POSIX spec. We used to discuss this daily.
Sorry I wouldn't have bothered a guru ;)
I've sure a lower experience then Your but I continue to prefer a high
threaded
application with fine grained locks.
It'll be prepared for well scaling SMP systems, that IMVHO will be the
future of computing,
rather than uniprocessor ones with 1e99 gates ;)
Anyway I'd like if You get a look at the patch.
I think that a logarithmic scheduler, bechmarks apart, helps Linux SMP to
scale better.
Cheers,
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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:24 EST