Well, I think I know the problem.
The PoD expects Guest domain to balloon to the Max memory when
getting start.
But in fact, I only have balloon driver installed in domain U,
but have no actual balloon work.
So that is, if we run out of PoD cache before balloon works, Xen
will crash domain(goto out_of_memory),
and at this situation, domain U swap(dom U can’t use swap memory)
is not available , right?
And when balloon actually works, the pod cached will finally
decrease to 0, and no longer be used any more, right?
In my understanding, Pod Cache is much like a memory pool used for
domain initialization, this remind me of tmem,
which is a pool of all host memory. But tmem needs to have host
OS modification, but since Pod supports hvm,
could we use this method to implement a tmem like memory
overcommit?
From:
Chu Rui [mailto:ruichu@xxxxxxxxx]
TO: tinnycloud
CC: xen-devel@xxxxxxxxxxxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx;
dan.magenheimer@xxxxxxxxxx
Subject: Re: [Xen-devel] Xen balloon driver discuss
I am also interested with tinnycloud's
problem.
It looks that the pod cache has been used
up like this:
if ( p2md->pod.count
== 0 )
goto out_of_memory;
George, would you please take a look on
this problem, and, if possbile, tell a little more about what does PoD cache
mean? Is it a memory pool for PoD allocation?
Home