On 02/21/2014 05:44 PM, Dr. David Alan Gilbert wrote:
It's not clear to me how much of this (or any) of this control loop should
be in QEMU or in the management software, but I would definitely agree
that a minimum of at least the ability to detect the situation and remedy
the situation should
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/21/2014 12:32 AM, Dr. David Alan Gilbert wrote:
I'm happy to use more memory to get FT, all I'm trying to do is see
if it's possible to put a lower bound than 2x on it while still maintaining
full FT, at the expense of performance
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/19/2014 07:27 PM, Dr. David Alan Gilbert wrote:
I was just wondering if a separate 'max buffer size' knob would allow
you to more reasonably bound memory without setting policy; I don't think
people like having potentially x2
Dr. David Alan Gilbert wrote:
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/19/2014 07:27 PM, Dr. David Alan Gilbert wrote:
I was just wondering if a separate 'max buffer size' knob would allow
you to more reasonably bound memory without setting policy; I don't think
On 02/20/2014 06:09 PM, Dr. David Alan Gilbert wrote:
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/19/2014 07:27 PM, Dr. David Alan Gilbert wrote:
I was just wondering if a separate 'max buffer size' knob would allow
you to more reasonably bound memory without setting policy; I
On 02/20/2014 07:14 PM, Li Guang wrote:
Dr. David Alan Gilbert wrote:
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/19/2014 07:27 PM, Dr. David Alan Gilbert wrote:
I was just wondering if a separate 'max buffer size' knob would allow
you to more reasonably bound memory without
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/20/2014 06:09 PM, Dr. David Alan Gilbert wrote:
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/19/2014 07:27 PM, Dr. David Alan Gilbert wrote:
I was just wondering if a separate 'max buffer size' knob would allow
you
On 02/21/2014 12:32 AM, Dr. David Alan Gilbert wrote:
I'm happy to use more memory to get FT, all I'm trying to do is see
if it's possible to put a lower bound than 2x on it while still maintaining
full FT, at the expense of performance in the case where it uses
a lot of memory.
The bottom
* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote:
On 02/18/2014 08:45 PM, Dr. David Alan Gilbert wrote:
+The Micro-Checkpointing Process
+Basic Algorithm
+Micro-Checkpoints (MC) work against the existing live migration path in
QEMU, and can effectively be understood as a live migration
On 02/19/2014 07:27 PM, Dr. David Alan Gilbert wrote:
I was just wondering if a separate 'max buffer size' knob would allow
you to more reasonably bound memory without setting policy; I don't think
people like having potentially x2 memory.
Note: Checkpoint memory is not monotonic in this
From: Michael R. Hines mrhi...@us.ibm.com
Wiki: http://wiki.qemu.org/Features/MicroCheckpointing
Github: g...@github.com:hinesmr/qemu.git, 'mc' branch
NOTE: This is a direct copy of the QEMU wiki page for the convenience
of the review process. Since this series very much in flux, instead of
* mrhi...@linux.vnet.ibm.com (mrhi...@linux.vnet.ibm.com) wrote:
From: Michael R. Hines mrhi...@us.ibm.com
Wiki: http://wiki.qemu.org/Features/MicroCheckpointing
Github: g...@github.com:hinesmr/qemu.git, 'mc' branch
NOTE: This is a direct copy of the QEMU wiki page for the convenience
of
On 02/18/2014 08:45 PM, Dr. David Alan Gilbert wrote:
+The Micro-Checkpointing Process
+Basic Algorithm
+Micro-Checkpoints (MC) work against the existing live migration path in QEMU, and can
effectively be understood as a live migration that never ends. As such,
iteration rounds happen at the
13 matches
Mail list logo
