RE: tmem on 4.1 (was [Xen-devel] Re: Freeze schedule)

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 12.01.11 at 19:32, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>> >>> On 11.01.11 at 19:28, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
>> wrote:
>> > After consultation with Keir, here's a revised proposal:
>> >
>> >   Feature submission freeze
>> >   after 31 Dec
>> >
>> >     New feature patches posted before this point can be committed
>> >     afterwards if they needed the time to get into shape.
>> >
>> >     New features not previously posted have missed the boat.
>> 
>> Based on 4.0 experience, I'm afraid we'll have to default-disable
>> tmem again for 4.1, since (to my knowledge) there hasn't been
>> much (if any) work to eliminate non-order-0 post-boot allocations.
> 
> I haven't tested it due to other commitments, but didn't someone
> (Tim?) submit a patch to change shadow tables to use order-0,
> and Keir submit a patch to change domain struct to order-0?

alloc_{domain,vcpu}_struct() use order 1, and both containing
one or more instances of cpumask_t this size is configuration
dependent.

> IIRC, that's not everything... I think passthrough uses order>0
> still... but I assumed the vast majority of the problem was solved.

Yes, pass-through is one violator, domain_create() is another,
all but one allocating d->nr_pirqs sized arrays (the one other
case being even worse in allocating a nr_irqs sized array of
struct timer).

Only the shadow mode case was addressed iirc.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel