From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xensource.com,
Dave Scott <Dave.Scott@eu.citrix.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Jan Beulich <JBeulich@novell.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
George Shuklin <nge@narod.ru>,
Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Linux Xen balloon driver "minimum target"
Date: Fri, 18 Jun 2010 08:24:39 -0700 (PDT) [thread overview]
Message-ID: <bdd17f28-12d7-4a01-beae-4d8c291d8194@default> (raw)
As recently re-pointed out by George Shuklin:
http://lists.xensource.com/archives/html/xen-devel/2010-06/msg00849.html
with brief reply commentary by Keir:
http://lists.xensource.com/archives/html/xen-devel/2010-06/msg00875.html
the Xen ballooning code in many distros contains a
"minimum target" to allow a domain to protect itself
against silly and accidental balloon settings, it being
frightfully easy for a typo or misunderstanding (e.g.
an integer intended to represent MB but, oops, the value
should be given in KB) to result in a guest or dom0 crash.
This code originated from Novell about two years ago:
http://lists.xensource.com/archives/html/xen-devel/2008-04/msg00143.html
and, in my experience, eliminated frequent bug reports that
"xm memset" resulted in unexpected crashes.
This minimum target is a bit over-conservative, especially
on machines with 1GB-2GB of memory. Also, the
"logarithmic function" is applied to different values in
different kernels, so is in some cases a function of the
config file's "maxmem" and in some cases a function of "memory".
Because the variations of this code are broad (and, in upstream
Linux, non-existent), posting a patch doesn't solve the problem.
So instead, I thought I would open a discussion with my opinions
and "solution". We'll keep this on xen-devel for now, but
perhaps should open the discussion to xen-users as well.
I am in favor of keeping the code AND inserting some form of
it in the upstream balloon driver. There are two forms
of policy it enforces: (1) don't let an admin do something
REALLY stupid; and (2) "stupid" is dependent on the amount
of guest physical memory. While I don't much like (2), I
don't see a way one can get (1) without (2).
As a partial answer, in my balloon driver implementation
(to support self-ballooning) I added an additional proc/sysfs
variable "min_target_kb". This is set during init to the
result of the "minimum target" algorithm and, once set,
is used as the minimum allowed ballooning target. BUT
this variable is writable, allowing the safety latch to
be overridden. As a result, a system admin must shoot himself
in the foot before accidentally shooting himself in the head.
Clearly this is still not an ideal solution, but it works
for me.
Comments?
next reply other threads:[~2010-06-18 15:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-18 15:24 Dan Magenheimer [this message]
2010-06-21 10:03 ` Linux Xen balloon driver "minimum target" George Dunlap
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=bdd17f28-12d7-4a01-beae-4d8c291d8194@default \
--to=dan.magenheimer@oracle.com \
--cc=Dave.Scott@eu.citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@novell.com \
--cc=jeremy@goop.org \
--cc=keir.fraser@eu.citrix.com \
--cc=nge@narod.ru \
--cc=xen-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).