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

[Xen-devel] 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


 


Rackspace

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