Hmmm... OK, would you mind putting an #ifndef NDEBUG around
the printk("...failing order...)" in tmem_relinquish_pages()
for now then? Cleaning this up properly is too much surgery
until post-4.0.
(Do you want an officially submitted patch?)
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Thursday, February 18, 2010 12:38 AM
> To: Dan Magenheimer; Jan Beulich
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH] tmem: fix to 20945 "When tmem is enabled, reserve
> a fraction of memory"
>
> 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
|
Home