[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Populate-on-demand memory problem



On 09/08/2010 09:48, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> Keir,
> 
> with Dietmar having tested this successfully, is there anything that
> keeps this from being applied to -unstable (and perhaps also 4.0.1)?

George needs to resubmit it for inclusion, with a proper changeset comment
and a signed-off-by line.

 -- Keir

> Jan
> 
>>>> On 27.07.10 at 15:10, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> Hmm, looks like I neglected to push a fix upstream.  Can you test it
>> with the attached patch, and tell me if that fixes your problem?
>> 
>>  -George
>> 
>> On Tue, Jul 27, 2010 at 8:48 AM, Dietmar Hahn
>> <dietmar.hahn@xxxxxxxxxxxxxx> wrote:
>>> Hi list,
>>> 
>>> we ported our system from Novel SLES11 using xen-3.3 to SLES11 SP1 using
>>> xen-4.0 and ran into some trouble with the pod stuff.
>>> We have a HVM guest and already used target_mem < max_mem on startup of
>>> the guest.
>>> With the new xen version we get
>>> (XEN) p2m_pod_demand_populate: Out of populate-on-demand memory! tot_pages
>> 792792 pod_entries 800
>>> I did some code revisions and looking at pod patches
>>> (http://lists.xensource.com/archives/html/xen-devel/2008-12/msg01030.html)
>>> to understand the behavior. We use the following configuration:
>>> maxmem = 4096
>>> memory = 3096
>>> What I see is:
>>>  - our guest boots with e820 map showing maxmem.
>>>  - reading xenstore memory/target returns '3170304' means 3096MB, 792576
>> pages
>>> Now our guest uses the target memory and gives back 1000MB via
>>> hypervisor call XENMEM_decrease_reservation to the hypervisor.
>>> 
>>> Later I try to map the complete domU memory into dom0 kernel space and here
>> I
>>> get the 'Out of populate-on-demand memory' crash.
>>> 
>>> As far as I understand (ignoring the p2m_pod_emergency_sweep)
>>> - on populating a page
>>>   - the page is taken from the pod cache
>>>   - p2md->pod.count--
>>>   - p2md->pod.entry_count--
>>>   - page gets type p2m_ram_rw
>>> - decreasing a page
>>>   - p2md->pod.entry_count--
>>>   - page gets type p2m_invalid
>>> 
>>> So if the guest uses all the target memory and gave back all
>>> the (maxmem-target) memory p2md->pod.count and p2md->pod.entry_count should
>>> be
>>> zero.
>>> I added some tracing in the hypervisor and see on start of the guest:
>>> p2m_pod_set_cache_target: p2md->pod.count: 791264 tot_pages: 791744
>>> This pod.count is lower then the target seen in the guest!
>>> On the first call of p2m_pod_demand_populate() I can see
>>> p2m_pod_demand_populate: p2md->pod.entry_count: 1048064 p2md->pod.count:
>>> 791264 
>> tot_pages: 792792
>>> So pod.entry_count=1048064 (4096MB) complies to maxmem but
>>> pod.count=791264 is lower then the target memory in xenstore.
>>> 
>>> Any help is welcome!
>>> Thanks.
>>> Dietmar.
>>> 
>>> --
>>> Company details: http://ts.fujitsu.com/imprint.html
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.