> : 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?
I'm not saying it is a trivial problem. The locking in IRIX isn't that bad,
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.
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. I think that is fairly well established by our
discussion. My original statement was to the effect of "striving to make
Linux run well on embedded controllers as well as large CPU machines will pull
it apart, because no one knows how to make an operating system that runs well
in both scenarios". This wouldn't necessarily be a bad thing, it could be a
kinship somewhat like RT linux, but trying to integrate the two goals into the
same code base seems like a cumbersome idea.
> : 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?
Because it isn't a trivial problem, and it is something that takes many
man-years of work.
> : > : 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.
Yes, and it's not SMP. Even the local nodes aren't SMP. By SMP I am
referring to UMA bus architectures, which the O2k is not. For a UMA setup, it
is way too easy to saturate the bus. So before jumping to conclusions, it
would have been nice to clarify terminology. Looking at an Origin from a
global view it might look symmetric, but looking at it from each node, it
clearly is not. Thus our differing use of SMP.
> : > : 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.
I didn't have time to read the papers, so I assumed you were making a case for
small clusters being better.
> 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?
No, I don't have numbers. The theory:
First of all, I'm only considering the number of contended locks, not the
number of locks taken. Uncontended locks don't add much significant overhead
other than possible cache effects. It is easy to have a series of database
requests that generate lots of contention in the database (I don't need to
give examples do I?). So I would imagine the number of contended locks would
be able to reach the same order of magnitude. Since contention has drastic
latency and performance effects, it makes perfect sense to increase the
granularity of the locks (in both the kernel and the database) to avoid it.
In any case, I think it is a good think for Linux to scale up past 8 cpus. I
wish that wouldn't hurt it's feasibility as a sleek embedded OS, but in
reality, sleek embedded OSes are most likely going to be done on custom chips
with custom bare bones kernels for absolute minimum latency and overhead.
Thus I don't see Linux as being practical to run on an embedded disk
controller.
That was my original point and I'm sick of going into off-topic tangents, so
can we please stop the tirade or take it offline?
-- Zachary Amsden zamsden@engr.sgi.com (650) 933-6919 09U-510 Core Protocols- 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