: I still have to argue very much against the feature adding comment. Not all
: features require locking, most of the time they can use the basic locking
: model already in place.
:
: A lock protects a data structure. If the locking model is specified nicely,
: it is also clear what linked data structures this affects, and how any of that
: is modified by reference counting. Some cases can be a bit obtuse (i.e.
: streams), but that is just a can of worms I don't want to open.
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?
: So to answer A, I take it I should present a summary of all kernel structures
: and the locking model involved with each of them? I conceed your point that
: one can't keep the whole thing in one's head at once, but it isn't necessary
: to do that. 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?
: > : I wasn't arguing that 16 way SMP is OK. Everyone knows it isn't.
: >
: > Geez, and this from the guy who said Linux needs to support "16-64 way SMP".
:
: SMP sucks for greater than 2-4 cpus. It is way too easy to saturate the bus.
Wow. I don't agree with that at all. You haven't gone and talked to
your own hardware people, right? If you had, you'd know that an Origin
doesn't have _A_ bus, it has a bunches of them, all wired together in
a hypercube. It's scalable as all get out.
It's the bloody OS that is the problem, not the hardware.
I have to admit that I'm even more surprised than usual by what is
coming out of SGI. Someone arguing OS design goals who apparently
doesn't understand hardware, not even their own companies' hardware.
Isn't that a little strange?
: > : Are you saying that clusters of small SMP machines are better?
: >
: > read these:
: > http://www.bitmover.com/llnl/smp.pdf
: > http://www.bitmover.com/llnl/labs.pdf
:
: Small clusters of machines are excellent for certain applications, like web
: and media serving. Transaction processing for enormous databases is another
: animal entirely, and I see that falling into the 4-32 CPU category. I haven't
: seen concrete results saying this would work better on a cluster or a large
: CPU machine.
So what does that have to do with the quoted papers?
: > : So the locking
: > : moves from the kernels to the application layer. You still have the same
: > : synchronization concerns, it's just a matter of what layer they are
: > : implemented at.
:
: > Err, if you had actually done this, you'd find that your statements
: > are unsupportable in practice. Please show me an application that has
: > anything, even with an order of magnitude, like the number of locks
: > taken/released per second in IRIX or Solaris.
:
: A distributed shared database can easily reach the same order of magnitude on
: the number of consistancy operations it needs to perform.
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.
Second of all, even on a single SMP system, I have never heard of anything
like what you are describing and I've personally run database benchmarks
and have never seend what you are describing. So if you have numbers to
back up your claim, that would be nice. If not, perhaps you can explain
the theory which lead you to this conclusion?
-
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