[Xen-devel] Re: [PATCH] tmem: fix to 20945 "When tmem is enabled, reserve a fraction of memory"

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

If you don't want verbosity in the failed-allocation path, remove your
printk. Notice non-tmem code doesn't make a noise in this case.
tmem_relinquish_pages() takes an order parameter, and the normal path
through the allocator unconditionally calls it. Hence it doesn't make sense
to logically separate order=0 from order>=9 in this case either, from the
p.o.v. of the caller.

 -- Keir

On 17/02/2010 21:49, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> Hi Keir --
> 
> Hmmm... one other consequence of the change you made to the patch
> (as checked in as 20955 in staging) is that every attempt to allocate
> any 2MB page for a new domain (when memory is scarce) will result
> in a complaint printk'ed from tmem_relinquish_pages() before
> the domain builder falls back to order==0 pages.  This
> verbosity is probably not desirable in a product, though
> it may be very desirable with debug enabled as we track
> down other order>0 allocations.
> 
> Changing back to the "goto fail" avoids the verbosity without
> losing the debug capability.
> 
> Dan
> 
>> -----Original Message-----
>> From: Dan Magenheimer
>> Sent: Wednesday, February 17, 2010 8:13 AM
>> To: Jan Beulich; Keir Fraser
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [PATCH] tmem: fix to 20945 "When tmem is enabled, reserve
>> a fraction of memory"
>> 
>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>>> Subject: Re: [PATCH] tmem: fix to 20945 "When tmem is enabled,
>> reserve
>>> a fraction of memory"
>>> 
>>>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 17.02.10 13:10 >>>
>>>> On 16/02/2010 18:30, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
>>> wrote:
>>>> 
>>>>> +        if ( order == 0)
>>>>> +            goto try_tmem;
>>>>> +        if ( order >= 9)
>>>>> +            goto fail;
>>>> 
>>>> Why not try_tmem in the case that order>=9, too, rather than fail
>>> outright?
>>> 
>>> It could be done that way, but wouldn't have any effect, as tmem
>>> doesn't even try to relinquish any memory when order > 0.
>> 
>> Correct.  To explain (if anyone is interested):
>> 
>> Tmem maintains queues of order==0 pages internally because
>> if a page is released to the xenheap/domheap, it must be scrubbed.
>> But tmem is highly likely to use the page again (and SOON).
>> If tmem immediately reclaims the page, the scrubbing is wasted
>> cycles.  But if it does not and some other xenheap/domheap allocation
>> obtains the page, the contents of an unscrubbed page could
>> reveal data from another domain so would be a potential
>> security hole.
>> 
>> When a domain is being created, a large number of pages
>> may be (scrubbed and) transferred from tmem to Xen/domheap.
>> While this transfer, in combination with the "buddying"
>> in xenheap/domheap, may result in some order>0 chunks of
>> memory, there is no guarantee that it will.
>> 
>> I considered adding some kind of "buddying" to tmem's "free"
>> pages (and the interface to tmem_relinquish_pages() from
>> alloc_heap_pages() allows for an order>0 to be requested),
>> but due to fragmentation it would only rarely have any
>> value, especially for order>1, so I never implemented it.
>> 
>> So, in the end, the real solution is to change any allocations
>> in Xen, at least any allocations that occur after dom0 is
>> running, to no longer require order>0 allocations.
>> 
>> Dan



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