All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andrés Lagar Cavilla" <andreslc@cs.toronto.edu>
To: Javier Guerra <javier@guerrag.com>
Cc: xen-devel@lists.xensource.com, xen-research@lists.xensource.com
Subject: Re: [Xen-users] Announcing the first release of SnowFlock
Date: Sat, 13 Sep 2008 19:37:12 -0400	[thread overview]
Message-ID: <48CC4EA8.6070306@cs.toronto.edu> (raw)
In-Reply-To: <90eb1dc70809121342oc4fe4aeucaaca5e7fee30087@mail.gmail.com>

The more technical details of memory on demand etc can be found in our 
technical report: 
http://www.cs.toronto.edu/pub/reports/csrg/578/csrg-578-snowflock-LagarCavilla2008.pdf
Thanks for your interest!
Andres
Javier Guerra wrote:
> On Fri, Sep 12, 2008 at 3:09 PM, Andres Lagar-Cavilla
> <andreslc@cs.toronto.edu> wrote:
>   
>> More technically:
>> Snowflock is our prototype implementation of the / Impromptu Cluster (IC)/
>> abstraction. In an IC, an application encapsulated inside a virtual machine
>> (VM) is swiftly forked into multiple copies that execute on different
>> physical hosts, and then disappear when the computation ends. ICs simplify
>> the development of parallel applications and reduces management burden by
>> enabling the instantiation of new stateful computing elements: workers that
>> need no setup time because they have a memory of the application state
>> achieved up to the point of forking. This approach combines the benefits of
>> cluster-based parallelism with those of running inside a VM.
>>
>> Snowflock provides swift parallel VM cloning that makes it possible for
>> Internet applications to deliver near-interactive performance for
>> resource-intensive highly-parallelizable tasks. Snowflock makes use of four
>> key techniques: /VM descriptors/ (condensed VM images that allow for
>> sub-second suspension of a running VM and resumption of a of replicas); a
>> /memory-on-demand/ subsystem that lazily populates the VM's memory image
>> during runtime; a set of / avoidance heuristics/ that minimize the amount of
>> VM memory state to be fetched on demand; and a /multicast distribution/
>> system for commodity Ethernet networking hardware that makes the overhead of
>> instantiating multiple VMs similar to that of instantiating a single one.
>>     
>
> just reading the docs.... i find it nice how you can drive the
> duplication of VMs from within the VM.  great for grids.
>
> could you elaborate about the memory-on-demand? i couldn't find
> anything about it on the manual, and it seems like a major advantage.
>
>   

      reply	other threads:[~2008-09-13 23:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-12 20:09 Announcing the first release of SnowFlock Andres Lagar-Cavilla
2008-09-12 20:42 ` Javier Guerra
2008-09-13 23:37   ` Andrés Lagar Cavilla [this message]

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=48CC4EA8.6070306@cs.toronto.edu \
    --to=andreslc@cs.toronto.edu \
    --cc=javier@guerrag.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-research@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.