memory_reservation bug?

memory_reservation bug?

[Mick Jordan]

Superficially this trace suggests a bug in the memory-reservation code:

Bootstrapping...
increase_reservation 155028 using 65536 .. returned 155028
increase_reservation 35596 using 220564 .. returned 35596
decrease_reservation 194384..256160 (61776) .. returned 61776
decrease_reservation 186634..194384 (7750) .. returned 7750
decrease_reservation 104935..186634 (81699) .. returned 81699
decrease_reservation 79981..104935 (24954) .. returned 24954
increase_reservation 122328 using 79981 (xVM) page_alloc.c:782:d172 
Over-allocation for domain 172: 262145 > 262144
(xVM) memory.c:127:d172 Could not allocate order=0 extent: id=172 
memflags=0 (5984 of 122328)
.. returned 5984

This is a domain starting with 256MB with maxmem at 1GB. The increase 
and decrease calls all return apparently correctly, but the final 
increase suggests that there is a miscounting of the allocated pages to 
the domain. This is Xen 3.1.4 and Solaris xVM (if that matters).

The "using" indicates where in the physmap the increase should occur and 
the range on the decrease is the pfns being given up.

I've looked at the code in memory.c and page_alloc.c and Xen certainly 
thinks tot_pages > max_pages for the domain when it reports the error.

The extent_order on the reservations is 0.

Any ideas?

Mick

Re: memory_reservation bug?

[Keir Fraser]

On 11/03/2009 17:32, "Mick Jordan" <Mick.Jordan@sun.com> wrote:

> I've looked at the code in memory.c and page_alloc.c and Xen certainly
> thinks tot_pages > max_pages for the domain when it reports the error.
> 
> The extent_order on the reservations is 0.
> 
> Any ideas?

Just because you called decrease_reservation() doesn't mean the pages
necessarily really got freed. If you still have mappings to them squirrelled
away then the free can be deferred.

 -- Keir

Re: memory_reservation bug?

[Mick Jordan]

[-- Attachment #1.1: Type: text/plain, Size: 820 bytes --]

On 03/11/09 11:08, Keir Fraser wrote:
> On 11/03/2009 17:32, "Mick Jordan" <Mick.Jordan@sun.com> wrote:
>
>   
>> I've looked at the code in memory.c and page_alloc.c and Xen certainly
>> thinks tot_pages > max_pages for the domain when it reports the error.
>>
>> The extent_order on the reservations is 0.
>>
>> Any ideas?
>>     
>
> Just because you called decrease_reservation() doesn't mean the pages
> necessarily really got freed. If you still have mappings to them squirrelled
> away then the free can be deferred.
>   
Ah, that explains it, thank you. I was taking the fact that the return 
value equaled the number I tried to decrease meant that it really did 
decrease by that amount. But, owing to a bug, I do in fact have mappings 
still lying around.

Xen really does need a developer manual -;)

Mick




[-- Attachment #1.2: Type: text/html, Size: 1320 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: memory_reservation bug?: memory holes

[Mick Jordan]

On 03/11/09 11:08, Keir Fraser wrote:
>
> Just because you called decrease_reservation() doesn't mean the pages
> necessarily really got freed. If you still have mappings to them squirrelled
> away then the free can be deferred.
>   
A related question. I assume it is ok to have holes in the physical 
memory, i.e. call decrease_reservation with a range << max_pfn. In this 
case, what are the rules for the value in the P2M table? Does Xen zero 
out the slot or is it the guest's responsibility?  save/restore must be 
able to determine that a hole exists.

Mick

Re: memory_reservation bug?: memory holes

[Keir Fraser]

On 11/03/2009 19:50, "Mick Jordan" <Mick.Jordan@sun.com> wrote:

> A related question. I assume it is ok to have holes in the physical
> memory, i.e. call decrease_reservation with a range << max_pfn. In this
> case, what are the rules for the value in the P2M table? Does Xen zero
> out the slot or is it the guest's responsibility?  save/restore must be
> able to determine that a hole exists.

The P2M is completely in your control. Xen doesn't care about it. The
toolstack cares about it only for save/restore -- there I think any invalid
value stuffed in an empty slot would work just fine.

 -- Keir