| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: tmem on 4.1 (was [Xen-devel] Re: Freeze schedule)
>>> 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
|
|
|
| |
|
Home