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 be
* 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 perf
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 lin
* 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 all
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 s
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
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
pe
* 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
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 patch
* 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 "li
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
* mrhi...@linux.vnet.ibm.com (mrhi...@linux.vnet.ibm.com) wrote:
> From: "Michael R. Hines"
>
> 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
From: "Michael R. Hines"
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
maintaing two copies
13 matches
Mail list logo
