[libvirt] [PATCH] lxc: suspend/resume support

Ryota Ozaki ozaki.ryota at gmail.com
Wed Sep 16 14:26:53 UTC 2009


On Wed, Sep 16, 2009 at 9:41 PM, Ryota Ozaki <ozaki.ryota at gmail.com> wrote:
> Hi Chris,
>
> On Wed, Sep 16, 2009 at 8:15 PM, Chris Lalancette <clalance at redhat.com> wrote:
>> It looks relatively good, but one suggestion and two missing pieces:
(snip)
>> Suggestion: it might be better to sleep for shorter periods of time here in a
>> loop.  That is, sleep for say 1 ms, check if it's changed, sleep for 1 ms, etc.
>>  If it doesn't appear after 500 ms, then fail.  That way you'll know about the
>> change faster.
>
> Sure. Current waiting time might be a bit lazy.
>
> With my experience, once the state of a loaded container gets FREEZING,
> it doesn't transit to FROZEN in short periods such as 1ms. So 50ms or
> somewhat is probably appropriate to avoid busy checking. OTOH, the max
> waiting time also might be able to be shorter than current 3 sec.,
> e.g., 500ms as you say or 1 sec. Actually a container staying FREEZING
> state for 1 sec. seems never transiting to FROZEN.
>
> For the moment, I'll try around 50ms interval and 500ms max waiting time.

OK, through additional observation, I found state transitions can be divided
two behaviors; One is under no or few load. In this case, the state of
a container seems quickly transiting to FROZEN and 1ms is enough. The other
is under heavy load. In this case, the state of a container takes several
tens or hundreds miliseconds or never go forward at worst. In this case,
50ms or less interval will just waste CPU time.

To address both behaviors with low overhead, I increase checking interval
by multiplying 10 starting 1ms, i.e., checking on 1ms, 10ms, 100ms and
1000ms where timeout is 1 sec. It is likely to treat both cases nicely.

Thanks,
  ozaki-r




More information about the libvir-list mailing list