: Principle 4: Accept that your wrong. If you constantly believe that every
: decision you make is right, you are deluded.
:
: Principle 5: Be humble.
These ones are good for everybody, both the guys that are learning and the
guys that have "been there, done that". One thing I'm trying to avoid
in my `old' age is to not get into this mode of saying "that won't work".
I think that if one believes that they know so much about it that they can
say it won't work, they also know enough to at least wack out a strawman
description of how it should work.
: First, checkpoint/restart, does anyone else support it?
Sure, lots of people do. IRIX does. And there are some people in Italy
(spain?) that are working on it for Linux. As to how, I think I have some
old docs on this somewhere, ping me if you want me to look 'em.
: What about an abstraction layer? You could have processes run ....
Yes, you need to abstract processes into "objects" similar to file "objects".
: We all can agree that you cannot checkpoint "sockets" for later use
Actually, you can, but it is not exactly easy. The degrees of "hardness" are
- UDP sockets saved/restored on the same host
- TCP sockets saved/restored on the same host
- UDP sockets saved then restored on a different host
- TCP sockets saved then restored on a different host
If you think about IP masquerading, you can start to see that just about
anything is possible in terms of redirection; it's just the saving and
restoring of the state that's a bitch. For sockets, you would really
like to wait until the input/output queues are drained but there is no
way to be sure that the input queue will be drained no matter how long
you wait - you may have stopped the process that was going to send the
message that was going to make another process drain a different queue.
So you have to take the data out of the queues, save it, and put it back
in. That's still not so hard, just a bunch of grunt work.
The hard one is TCP - UDP is stateless (for the most part) so you can just
take the data and shove it into some other queue and it should mostly work.
TCP has state, and that state is normally built up incrementally over the
life of the connection. When you are restoring a TCP connection, you
need to establish the connection and then wack the sockets so they think
they are in the right state so that the data you stuff in the queues
won't be rejected by the kernel.
Now add the idea that you want to start the process up on some other system.
You basically are going to have to forward the data from the old host to
the new host. Yuck. Again, it can be done, it's just another level of
complexity.
: Ultimately the question is: Does Linus want Linux to become this
Linus and I have discusse this several times. I believe that he is still of
the opinion that heavily multi threading the kernel is a bad idea. The general
plan is to make the kernel scale to about 4 processors and then use clustering
for scaling beyond that.
One thing I do know: Linus will not accept changes into the system for
clustering which slow down the non-clustered performance of the system.
--- Larry McVoy lm@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 majordomo@vger.rutgers.edu