Xen project Mailing List

On 1/7/09, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:

> Since you're changing the name anyway, can't we change the users of
> the file to understand the new units too ?

The patch should be easy, it's the change to backwards compatibility
that should be discussed, both for xen distros and now for upstream
Linux as well.  I suspect this isn't used much (yet) but don't know.

Writing bytes to a sysfs entry called target_kb is a bug
I think.  Is there precedence for having one sysfs entry for
reading and another for writing (the same value)?

>> 2) There is no "safety minimum", so writing the same value back
>>    actually reduces memory by a factor of 1024!

> I guess this just needs porting forward.

I vaguely recalled and so went and found this post from Jeremy:
http://lists.xensource.com/archives/html/xen-devel/2008-04/msg00144.html
(so Jeremy cc'ed)

So is it better to have the existing static model, or none
at all, or discuss and implement something better?

One option might be to have a writable sysfs min-mem which defaults
to the computed-from-maxmem value (from Jan's patch) but can
be overridden**.  That way, just changing target won't accidentally
cause OOMs but more aggressive ballooning can also be done.

I think that's definitely the right thing, and I'd just started familiarizing myself with the balloon driver source with the intent to add that functionality. An appliance or "instant-on" vm starting from a saved snapshot state would want to aggressively balloon memory down to the absolute minimum before saving and then balloon on restore. The computed-from-maxmem min-mem value doesn't work very well for this use case.

-- Trolle

Dan

** and bytes? kb? mb? :-)

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Wednesday, January 07, 2009 4:42 AM
> To: Ian Campbell
> Cc: Dan Magenheimer; Xen-Devel (E-mail)
> Subject: Re: [Xen-devel] 2.6.28 and balloon driver
>
>
> Ian Campbell writes ("Re: [Xen-devel] 2.6.28 and balloon driver"):
> > Looks like the write function uses memparse which
> understands the M, K
> > etc suffixes and defaults to bytes. The ability to say
> balloon to <n>M
> > is quite nice but for the sake of consistency with the name it's
> > probably preferable to just treat the value as a number of Kbytes.
>
> Since you're changing the name anyway, can't we change the users of
> the file to understand the new units too ?
>
> Ie, I think we should have
>   /sys/devices/system/xen_memory/xen_memory0/targe
> which when read produces a number of bytes and which uses the default
> memparse function.  If nothing else this is more likely to be
> something upstream mind less.
>
> Ian.
>

On Tue, 2009-01-06 at 23:34 +0000, Dan Magenheimer wrote:
> I am playing with 2.6.28 on xen.  Nice!  Thanks Jeremy!
>
> But I have a minor gripe...
>
> The balloon driver now is accessed via a sysfs file, for example:
>
> # SIZE=`cat /sys/devices/system/xen_memory/xen_memory0/target_kb`
> # echo $SIZE
> # echo $SIZE > /sys/devices/system/xen_memory/xen_memory0/target_kb
>
> SIZE does indeed get current memory size in kbytes, but
> if one tries to pass SIZE (or slightly smaller value) back,
> all hell breaks loose because:
>
> 1) Despite the name, the value written must be in bytes, not kbytes

Looks like the write function uses memparse which understands the M, K
etc suffixes and defaults to bytes. The ability to say balloon to <n>M
is quite nice but for the sake of consistency with the name it's
probably preferable to just treat the value as a number of Kbytes.

> 2) There is no "safety minimum", so writing the same value back
>    actually reduces memory by a factor of 1024!

I guess this just needs porting forward.

Can you provide patches for both these issues?

Ian.

>
> I realize behavior (1) is backwards-compatible with the existing
> /proc/xen/balloon behavior, but at least that filename doesn't
> imply a unit size.
>
> For (2), as sysadmins grow comfortable with the "safety minimum"
> that's been implemented in upstream xen now for nearly a year,
> (users can do:
>
> # echo 0 > /proc/xen/balloon
>
> and it still works), some people upgrading to a 2.6.28 kernel
> are in for a nasty surprise.
>
> <gripe off>

_______________________________________________

Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel