From: Michael Concannon <mike@concannon.net>
To: lokum spand <lokumsspand@hotmail.com>
Cc: arjan@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: A possible idea for Linux: Save running programs to disk
Date: Sat, 01 Oct 2005 19:09:50 -0400 [thread overview]
Message-ID: <433F173E.2020108@concannon.net> (raw)
In-Reply-To: <BAY105-F2270EEA37B83483AE53063A48E0@phx.gbl>
>>>>
>>>> Suppose Linux could save the total state of a program to disk, for
>>>> instance, imagine a program like mozilla with many open windows. I
>>>> give
>>>> it a SIGNAL-SAVETODISK and the process memory image is dropped to a
>>>> file. I can then turn off the computer and later continue using the
>>>> program where I left it, by loading it back into memory.
>>>>
>>>> Would that be possible? At least a program can be given a ctrl-z
>>>> and is
>>>>
>>>>
>>>
>>> there is a LOT of state though.. the moment you add networking in the
>>> picture the amount of state just isn't funny anymore. Your X example is
>>> a good one as well...
>>>
>>>
>> There are a few cluster/parallel computing libraries out there that
>> are starting to allow "process migration"...
>>
>> One would assume that "saving it to a disk" is simply a degenerate
>> case of migrating the process...
>>
>> Presuming they have process migration working (and it seemed close a
>> while ago when I last looked), saving to a file might already be
>> supported... I'd google "process migration" and you are likely to
>> find a lot of discussion on this topic...
>>
>> /mike
>>
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>>
>>>
>>
>
> In fact moving processes from one machine to another would be a
> brilliant feature at my work, since we run fairly large and
> time-consuming simulations on electronic circuits. If the kernel could
> natively support bouncing jobs back and forth, that would really be
> something. Since we simulate with proprietary software, I suppose we
> can't rely on the simulator being rewritten to support such special
> libraries.
>
> Does any other Unix variant have process bouncing already?
Yes, plenty of proprietary tools in that space... This is something
Big-Iron has needed to do for quite a while - if nothing else
fault-tolerance requires migrating processes of dead or dying nodes.
More recently some of the gnu stuff has come up to speed - though, I
must admit it has been a while since I looked...
For the gnu world, have a look at "mosix" - but again, groups.google.com
and search for "process migration"... I am sure there have been
developments in the time since I last looked at it... I satisfied my
needs with gridengine as the least invasive way to deal with load
balance of EDA tools without having to use $LSF. My requirements at the
time were - "can I get it running and use it in an hour...", So, I doubt
it was the best or only choice...
The goal of most of the clustering libraries is that it is transparent
to the tool, but flexlm causes trouble even if you don't do screwy
things, so YMMV. At this point I have exhausted my expertise on the
subject :-).
search terms:
gridengine
PVM
mosix
cluter
process migration
/mike
next prev parent reply other threads:[~2005-10-01 23:09 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-01 21:30 A possible idea for Linux: Save running programs to disk lokum spand
2005-10-01 21:39 ` Arjan van de Ven
2005-10-01 22:21 ` Michael Concannon
2005-10-01 22:51 ` lokum spand
2005-10-01 23:09 ` Michael Concannon [this message]
2005-10-02 8:30 ` Tomasz Torcz
2005-10-02 13:31 ` Benoit Boissinot
2005-10-02 18:49 ` Jon Masters
2005-10-02 19:21 ` Lexington Luthor
2005-10-02 0:34 ` grundig
2005-10-02 4:53 ` Bernard Blackham
2005-10-02 12:57 ` Ed Tomlinson
2005-10-02 14:16 ` Bernard Blackham
2005-10-10 1:13 ` serue
2005-11-06 15:42 ` Bernard Blackham
2005-11-09 2:15 ` Peter Chubb
2005-10-02 5:36 ` Andrew Haninger
2005-10-03 17:41 ` Adrian Bunk
2005-10-03 18:52 ` Andrew Haninger
2005-10-03 18:59 ` Adrian Bunk
2005-10-03 19:48 ` Andrew Haninger
2005-10-02 18:46 ` Jon Masters
[not found] <4SXfo-7hM-9@gated-at.bofh.it>
2005-10-02 3:19 ` Bodo Eggert
[not found] ` <4T47e-5E-1@gated-at.bofh.it>
[not found] ` <4TbLq-2VG-5@gated-at.bofh.it>
[not found] ` <4TcR9-4sS-9@gated-at.bofh.it>
2005-10-02 17:08 ` Bodo Eggert
2005-10-02 17:51 ` Bernard Blackham
2005-10-02 19:13 ` Jeff Dike
2005-10-03 20:02 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=433F173E.2020108@concannon.net \
--to=mike@concannon.net \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokumsspand@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox