Re: [Openmosix-devel] [RFC] About 2.6

[Peter C. <pe...@co...>]

On Fri, May 28, 2004 at 11:43:24PM +0000, Matthias Rechenburg wrote:
> Hi Tab,
>=20
> On Freitag 28 Mai 2004 12:05, Vincent Hanquez wrote:
> > 	Hi list,
> >
> > Sorry for having keep 'secret' the 2.6 plan.
>=20
> ;)
>=20
> > So, here short version of the plan:
> >
> > * moving all we can to userspace

 Definitely a good idea for the long run.  I was surprised how much was in
kernel space :-)

> > {{{moving all we can to userspace}}}

> yes to all above.... we may just consider to leave=20
> "performance dependent code" in the kernel-space.
> e.g. if a system is under heavy load (what we can expect) to my
> mind the scheduler won't pick up the user-space openMosix "stuff"
> often enough to be performant.

 That's what nice =3D -19 is for.  Or real-time priority, but then an infin=
ite
loop would give you a hung system.

> > {{{separate arch dependant/independant code}}}
> >
> > Arch dependant code are carefully move to specific arch directory.
> > At this time openMosix support:
> > 	- i386
> > 	- x86_64
> > 	- ppc
> > But not at the same level, and i386 is still the first arch to work on.

 Well that's as it should be.  I see your latest 2.4.26 patch has changes to
arch/x86_64.  Is that useable now?  I never heard anything about it.  (did
you write that code?)  I had been waiting to hear an answer as to why the
patch only had changes to entry.S in arch/ia64, but changed lots of files in
arch/i386.

 I'll have a 22CPU dual-Opteron cluster arriving sometime next month, and I
already have a cluster where I'm experimenting with 64bit non-oM kernels.

 Anyway, is 2.4.x x86_64 close enough to stable to be worth looking at?
=20
 If I ran a 2.6 x86_64 kernel on a couple cluster nodes to hack on, how
likely would it be that jobs started on them but node-locked would crash?
i.e. can I hack oM on a cluster that people are using, if I don't enable
migration for other people's jobs?  Or would it be better to use an emulator
like Mulyadi's latest dojo describes. :)

> > {{{todo}}}
> >
> > * kernelspace:
> > 	- Control migration back for remote process.
> > 	- Remote syscalls.

 What are you going to do about x86-64 vsyscalls for gettimeofday for
migrated processes?  Make them fall back to normal context-switching calls
for migrated processes only, if possible?  Or let processes see the local
system time?

> > 	- Remote signals.
> > 	- authorized ip system

 Some kind of access control sounds like a good idea, unless we want to
simply leave that to iptables.  OTOH, the general rule is that it's a Good
Thing to set up access control to be secure without a firewall, and the
firewall is just another layer of protection.
See arch/x86_64/kernel/vsyscall.c in a 2.4 kernel.  (I don't think it gets
used unless libc wants to, though.)

> > 	- (?) auth (crypto, whatever...)

 Leave crypto to lower communication layers.  Would there be any benefit to
duplicating the functionality of IPSEC in openMosix?  Maybe a slight
performance advantage when sending a large chunk of memory, since we
wouldn't have to worry about a different key for each packet, or something.
It's very hard to get packet-by-packet crypto right.  Look at WEP.  Not even
a whole bunch of professionals got that right.  There was an article a while
ago, which I can't find right now, about crypto mistakes in many Free
software attempts at crypto network tunnels or VPNs that used a custom
protocol rather than IPSEC.

> > * userspace:
> > 	- write a information/autobalance daemon to substitute old kernelspace
> > 	2.4 daemons.

 Any plans to modify/re-design any protocols, to take advantage of
broad/multicast, or use IPv6?  (v6 requires multicast to work, IIRC, so we
can count on having multicast when using IPv6).  A multicast info protocol
would require something to mitigate the migration storms that would result
if a process finished, and an un-loaded node announced to several other
nodes simultaneously that it was free.

--=20
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC