New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory seen by a _service_ VM is different than set in Dom0 #259

Closed
marmarek opened this Issue Mar 8, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@marmarek
Member

marmarek commented Mar 8, 2015

Reported by joanna on 2 Jul 2011 10:53 UTC
free -m shows larger amount of memory than set via qvm-pref, and reported by qvm-ls.

Migrated-From: https://wiki.qubes-os.org/ticket/259

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by rafal on 20 Jul 2011 11:34 UTC
This looks like the kernel bug. Affects not only servicevms.
This is "fixed" by qmemman doing xl memset. That is why it is not visible in normal appvms. However, if I "xl start" an appvm manually with init=/bin/bash, there is a similar difference visible as well.

I think simply the memory amount reported by /proc/meminfo is miscalculated. If I do

xl memset firewallvm 199
xl memset firewallvm 200

then there is no change in xen free memory (or vms memory), but the meminfo shows 200 correctly then.

It can be worked around by adding

MEMKB=$(grep Current /proc/xen/balloon|sed -e 's/ kB//' -e 's/.* //')
echo $((($MEMKB-1)*1024)) > /proc/xen/balloon

somewhere in a VM init.d script. Or do we want to file a ticket for suse folks and wait for a clean solution ?

Member

marmarek commented Mar 8, 2015

Comment by rafal on 20 Jul 2011 11:34 UTC
This looks like the kernel bug. Affects not only servicevms.
This is "fixed" by qmemman doing xl memset. That is why it is not visible in normal appvms. However, if I "xl start" an appvm manually with init=/bin/bash, there is a similar difference visible as well.

I think simply the memory amount reported by /proc/meminfo is miscalculated. If I do

xl memset firewallvm 199
xl memset firewallvm 200

then there is no change in xen free memory (or vms memory), but the meminfo shows 200 correctly then.

It can be worked around by adding

MEMKB=$(grep Current /proc/xen/balloon|sed -e 's/ kB//' -e 's/.* //')
echo $((($MEMKB-1)*1024)) > /proc/xen/balloon

somewhere in a VM init.d script. Or do we want to file a ticket for suse folks and wait for a clean solution ?

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 25 Jul 2011 08:13 UTC
File a ticket (perhaps to xen-devel as well?). Moving this to Beta 3. Reducing this to minor (and perhaps we will move it to Beta 3, while waiting for the official fix).

Member

marmarek commented Mar 8, 2015

Comment by joanna on 25 Jul 2011 08:13 UTC
File a ticket (perhaps to xen-devel as well?). Moving this to Beta 3. Reducing this to minor (and perhaps we will move it to Beta 3, while waiting for the official fix).

@marmarek marmarek added P: minor and removed P: major labels Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 28 Jul 2011 09:34 UTC

Member

marmarek commented Mar 8, 2015

Modified by joanna on 28 Jul 2011 09:34 UTC

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 18 Jan 2012 10:12 UTC
It doesn't seem to harm anybody, and is strictly a Xen/kernel problem.

Member

marmarek commented Mar 8, 2015

Comment by joanna on 18 Jan 2012 10:12 UTC
It doesn't seem to harm anybody, and is strictly a Xen/kernel problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment