On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
> * Nikunj A. Dadhania <nikunj@xxxxxxxxxxxxxxxxxx> [2010-09-28 15:26:30]:
<snip>
> > + /* Extract other memory tunables */
> > + if (virXPathULong("string(./memtune/hard_limit)", ctxt,
> > + &def->mem.hard_limit) < 0)
> > + def->mem.hard_limit = 0;
> > +
> > + if (virXPathULong("string(./memtune/soft_limit[1])", ctxt,
> > + &def->mem.soft_limit) < 0)
> > + def->mem.soft_limit = 0;
> > +
> > + if (virXPathULong("string(./memtune/min_guarantee[1])", ctxt,
> > + &def->mem.min_guarantee) < 0)
> > + def->mem.min_guarantee = 0;
> > +
> > + if (virXPathULong("string(./memtune/swap_hard_limit[1])", ctxt,
> > + &def->mem.swap_hard_limit) < 0)
> > + def->mem.swap_hard_limit = 0;
> > +
>
> Quick question, does 0 represent invalid values?
If configuration file does not provide any value, we set this to 0, we
do not call the lower layer calls in this case.
> I'd presume you'd
> want to use something like -1. We support unsigned long long for the
> values to be set (64 bit signed), unlimited translates to 2^63 - 1, is
> ULong sufficient to represent that value?
The unit here is KB, so we can have till 2^42 bytes. So to answer you
question, no it does not represent 64 bit signed. I guess this should not be
an issue to support if needed.
I understand that in case of cgroup unlimited is (-1), but again that
would be cgroup specific at this level. I need to think of some way to address
this independent of the lower layer.
> > + unsigned long hard_limit;
> > + unsigned long soft_limit;
> > + unsigned long min_guarantee;
> > + unsigned long swap_hard_limit;
>
> The hard_limit, soft_limit, swap_hard_limit are s64 and the value is
> in bytes. What is the unit supported in this implementation?
KB
Thanks for reviewing.
Regard
Nikunj
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list