I never said that I didn't. I'm just taking issue with the choosen path
which has been demonstrated to not work.
"Let's scale Linux by multi threading"
"Err, that really sucked for everyone who has tried it in the past, all
the code paths got long and uniprocessor performance suffered"
"Oh, but we won't do that, that would be bad".
"Great, how about you measure the changes carefully and really show that?"
"We don't need to measure the changes, we know we'll do it right".
And just like in every other time this come up in every other engineering
organization, the focus is in 2x wherever we are today. It is *never*
about getting to 100x or 1000x.
If you were looking at the problem assuming that the same code had to
run on uniprocessor and a 1000 way smp, right now, today, and designing
for it, I doubt very much we'd have anything to argue about. A lot of
what I'm saying starts to become obviously true as you increase the
number of CPUs but engineers are always seduced into making it go 2x
farther than it does today. Unfortunately, each of those 2x increases
comes at some cost and they add up.
----- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/