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