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
|
Home