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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.01.13 at 19:10, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> 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?

Fragment or exhaust. In the latter case an allocation request
will trigger it to release _individual_ pages, and hence to have
only a very slim chance to get an allocation request for any
number of contiguous pages to be satisfied.

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

None, you should break up the allocation (if it needs to be this big
in the first place). Considering the use case here, using the
recently added vmap() to map the individual pages into a
contiguous linear range might be an option. If you go that route,
we would then also need to evaluate whether the address range
reserved for this is big enough.

Jan


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