: > Once again, you haven't answered the questions. How many locks would
: > it take? Why is it that there are no examples of systems that work like
: > what you describe and basically all real examples (Solaris, IRIX, AIX,
: > HP-UX) work like what I describe?
:
: I'm not saying it is a trivial problem. The locking in IRIX isn't that bad,
It's not? And your basis for that statement is what? Have you sat
watching the lock traffic with a logic analyzer on an IRIX machine?
Have you talked to someone who has? Have you counted the locks?
How about the classes of locks? Have you talked to the hardware people
who have to make hardware which supports your use of locks? Do you
know what percentage of the coherency directories on an origin are
used up by OS traffic vs application traffic?
: but it is impossible to give a figure on the number of locks because the
: number changes based on load on the various components. I don't have an
: figure, and I'm not about to make one up off the top of my head.
Are you arguing that the IRIX locking is fine, without any data whatsoever
to support that point of view? When I was at SGI, I spent a fair amount
of time looking at this, from a software position and a hardware position,
and it was a really common topic of discussion amongst the engineers.
It was widely agreed that the locking was a huge problem and the OS,
NOT THE APPLICATION, the OS,
stressed the locking hardware way beyond what it was capable of supporting.
Kind of seems counter to what you are saying, doesn't it?
: My original point was that no vendor has sucessfully solved the problem of
: having a kernel that scales well and is light weight enough to work in
: embedded applications as well.
So, your position is "Linux isn't light enough to do the embedded job so
let's bloat it up so we can handle the 64 processor case". Let's see.
Millions of disk drives, millions of laptops, millions of small devices.
How many 64 processor systems installed the world? Come again?
: > : The locking model can be clearly formulated and intuitive on each
: > Can it? Like I said, 3 times I think, please point me at an example
: > of it. Multi threading is a well understood area, quite mature, so there
: > should be no problem trotting out a mature, multi threaded OS which is
: > not a locking nightmare. So _where_ is it?
: >
: > And if you can't find it, ask yourself why not?
:
: Because it isn't a trivial problem, and it is something that takes many
: man-years of work.
That's just dodging the question. We've had many years of multithreading,
VMS, UNIX, all sorts of operating systems are threaded. So where's the
one shining example which proves your point?
The problem with your position is that given the fact that there are
years of threading experience behind us, the only answer which makes
sense is that the people who came before you didn't have the talent to
get their locking model right. You keep asserting that it can be done
and that sort of looks like you think you are smarter than the collective
experience of the last 20 years of OS engineers.
As much as I would love to think that you are that smart, statistics
are heavily against it. If we can postulate that you are as good as the
best who have come before you, but no better, then it seems a foregone
conclusion that letting you go to town on the locking problem would
result in another IRIX or Solaris.
I certainly don't speak for the rest of the kernel guys, but I'll bet
that IRIX/Solaris is not where they want Linux to go.
: > First of all, we're talking numbers for SMP platforms, which should make
: > it even easier for you to make your point - a distributed system usually
: > has much higher latency so the numbers would be dramatically lower,
: > they have to be, think about it.
:
: I didn't have time to read the papers, so I assumed you were making a case for
: small clusters being better.
So, in summary, you don't have any data, your theories seem unsupported
by either the written work in the field or practical experience, and
you don't have time to read anything which might educate you, but you
still have plenty of opinions.
Well, you have chutzpah, I'll give you that.
-
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 : Tue Feb 15 2000 - 21:00:24 EST