On 09.08.2013 18:29, Daniel P. Berrange wrote:
On Fri, Aug 09, 2013 at 10:58:55AM -0500, Anthony Liguori wrote:
Michal Privoznik mpriv...@redhat.com writes:
[CC'ing qemu-devel list]
On 09.08.2013 15:17, Daniel P. Berrange wrote:
On Fri, Aug 09, 2013 at 07:13:58AM -0600, Eric Blake wrote:
On
On Mon, Aug 19, 2013 at 10:29:10AM +0200, Michal Privoznik wrote:
On 09.08.2013 18:29, Daniel P. Berrange wrote:
On Fri, Aug 09, 2013 at 10:58:55AM -0500, Anthony Liguori wrote:
Michal Privoznik mpriv...@redhat.com writes:
[CC'ing qemu-devel list]
On 09.08.2013 15:17, Daniel P. Berrange
On 19.08.2013 11:06, Daniel P. Berrange wrote:
On Mon, Aug 19, 2013 at 10:29:10AM +0200, Michal Privoznik wrote:
On 09.08.2013 18:29, Daniel P. Berrange wrote:
On Fri, Aug 09, 2013 at 10:58:55AM -0500, Anthony Liguori wrote:
Michal Privoznik mpriv...@redhat.com writes:
[CC'ing qemu-devel
[CC'ing qemu-devel list]
On 09.08.2013 15:17, Daniel P. Berrange wrote:
On Fri, Aug 09, 2013 at 07:13:58AM -0600, Eric Blake wrote:
On 08/09/2013 06:56 AM, Michal Privoznik wrote:
This function is to guess the correct limit for maximal memory
usage by qemu for given domain. This can never be
Michal Privoznik mpriv...@redhat.com writes:
[CC'ing qemu-devel list]
On 09.08.2013 15:17, Daniel P. Berrange wrote:
On Fri, Aug 09, 2013 at 07:13:58AM -0600, Eric Blake wrote:
On 08/09/2013 06:56 AM, Michal Privoznik wrote:
This function is to guess the correct limit for maximal memory
Am 09.08.2013 17:58, schrieb Anthony Liguori:
Even if we had an algorithm for calculating memory overhead (we don't),
glibc will still introduce uncertainty since malloc(size) doesn't
translate to allocating size bytes from the kernel. When you throw in
fragmentation too it becomes extremely
On Fri, Aug 09, 2013 at 10:58:55AM -0500, Anthony Liguori wrote:
Michal Privoznik mpriv...@redhat.com writes:
[CC'ing qemu-devel list]
On 09.08.2013 15:17, Daniel P. Berrange wrote:
On Fri, Aug 09, 2013 at 07:13:58AM -0600, Eric Blake wrote:
On 08/09/2013 06:56 AM, Michal Privoznik