DragonFly users List (threaded) for 2007-02
DragonFly BSD
DragonFly users List (threaded) for 2007-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: vkernel migration

From: "Dmitri Nikulin" <dnikulin@xxxxxxxxx>
Date: Thu, 1 Feb 2007 10:36:27 +1100

On 2/1/07, Nigel Weeks <nweeks@examiner.com.au> wrote:
Just an idea for thought over your next coffee...

I'm if it would be to conceivably possible to move a vkernel process(and any
sub-processes it had) to another host? It'd have to stop temporarily, or at
least, slow down immensely while pumping all the userland data inside the
vkernel to the other host.

It might just be easier to have a vkernel powered by multiple physical
kernels (on different machines), giving the appearance of an SMP machine
inside the vkernel.

(Insert 40,000 lines of code here...)

The considerations are mostly the same for real kernels - you have to ensure the resident image of the process will still reference the right host entities like file descriptors, etc. The virtual kernel can help by insulating its processes from the specifics of the host kernel, but the virtual kernel itself uses those specifics a lot too. Basically, the system has to be practically identical for migration to work.

A great example is already in DragonFly - process checkpointing. I
don't even know how it works as well as it does. It can't magically
switch CPU architectures or compensate for changes in kernel
structures, but it can do a lot more than I thought practical.

As an aside, a few months ago I was thinking about distributed
processing, and that in increasingly heterogeneous networks it's
harder to just migrate processes directly.

The SMP thing you described is a nature of many SSI systems already,
but again, it requires deploying precisely the same environment in so
far as the user processes should not have any sudden changes that
can't be explained in terms of hotplugging. E.g. changing available
RAM is fine because virtual memory makes up for that, but suddenly
removing MMX support really isn't, since the process could have been
in the middle of an MMX instruction set when it was frozen - and
voluntary preemption in this is fraught with problems. Then you have
to "bind" some processes to their hosts because they directly mmap a
device, for instance.

IMPORTANT NOTICE - The contents of this e-mail may be confidential and is
intended only for the individual(s) or entity(s) named herein. Any
unauthorised use of the contents is expressly prohibited. If you have
received the e-mail in error, please contact the sender by telephone
immediately and then delete the e-mail. We cannot guarantee that this
e-mail, attachments or Internet links are free of computer viruses that may
damage or interfere with data, hardware or software or contains material
that may contravene local, national or International laws. Opening of this
e-mail is acceptance on the part of the recipient(s) that he or she accepts
full responsibility for protecting their computer and associated software
and systems from any such viruses and materials and absolves Rural Press

What? "Opening this e-mail is acceptance of the terms specified in this e-mail"?

Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]