RE: [Xen-devel] 2.6.28 and balloon driver

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> 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.

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