Re: [Xen-devel] [RFC PATCH V2 13/14] Infrastructure for manipulating 3-level event channel pages

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, 2013-01-29 at 08:43 +0000, Jan Beulich wrote:
> >>> On 28.01.13 at 18:21, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > On Mon, 2013-01-21 at 16:50 +0000, Jan Beulich wrote:
> >> >>> On 21.01.13 at 15:30, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >> > +    evtchn_pending = xzalloc_array(xen_pfn_t, r.nr_pages);
> >> > +    evtchn_mask = xzalloc_array(xen_pfn_t, r.nr_pages);
> >> > +    l2sel_mfns = xzalloc_array(xen_pfn_t, r.nr_vcpus);
> >> > +    l2sel_offsets = xzalloc_array(xen_pfn_t, r.nr_vcpus);
> >> 
> >> While the former two are okay, the latter two aren't since
> >> this can easily amount to an allocation of more than a page.
> >> This needs to be broken up.
> >> 
> > 
> > Judging from the code, the underlying _xmalloc is able to handle
> > situation when allocation is more than a page, isn't it?
> 
> Oh, yes, it is capable of doing so, and it is fine to call it that
> way at boot time. But any such allocation at run time is prone
> to fail just because of memory fragmentation (and they are
> particularly bad when tmem is active). We've gone through

So what exactly does tmem do in this case? It will fragment xenheap
eventually?

> the code several times to eliminate such run time allocations,
> so I don't see us permitting you to re-introduce such.
> 

_xmalloc calls alloc_xenheap_pages if size is bigger than PAGE_SIZE. If
tmem fragments xenheap, which API should I use here?

> And you should, just for future consideration, also take note
> of xmalloc() allocations being inefficient for exact page size
> (or multiple thereof) allocations.
> 

NP.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel