Konrad Rzeszutek Wilk wrote:

On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:

Hi maintainers,

I found there is an issue when 'xm save' a pvm guest. See below:

When I do save then restore once, CPU(%) in xentop showed around 99%.
When I do that second time, CPU(%) showed 199%

top in dom0 showed:
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
   4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block

I could kill the block process, then all look normal again.


What is the 'block' process? If you attach 'perf' to it do you get an idea
of what it is spinning at?

It's /etc/xen/scripts/block
I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
When domU was created first time, claim_lock/release_lock finished quickly,
when 'xm save' was called, claim_lock spin in its own while loop.
I can ensure no other domU create/save/etc happen when I test.

xen and xen-tools are both generated with xen-unstable.
I tried xl, but it segfault.


It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
the guest?

When xl create vm.cfg

I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
can't reproduce.


So the issue is only present with Xen-unstable?

Yes, I found in /etc/xen/scripts/locking.sh of ovm3.1.1, func claim_lock is quite different to xen-unstable
Maybe this is why ovm3.1.1 work with save/restore.

Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?

No, I built xen and xen-tools on el5, then installed to ovm3.1.1 on other partition.
thanks
zduan