[Xen-devel] "Deprecate" order>0 allocations? (was: [PATCH 1 of 2] Global virq for low memory situations)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, February 29, 2012 1:54 AM
> To: Dan Magenheimer
> Cc: ian.campbell@xxxxxxxxxx; ian.jackson@xxxxxxxxxx; adin@xxxxxxxxxxxxxx; 
> andres@xxxxxxxxxxxxxx;
> Andres Lagar-Cavilla; xen-devel; tim@xxxxxxx
> Subject: RE: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
> 
> >>> On 29.02.12 at 00:50, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> > Or maybe Jan's recent work has eliminated all but the corner
> > cases of order>0 allocations?  (/me crosses fingers)
> 
> I'm unaware of remaining violators of this, but I'm also not constantly
> monitoring.
> 
> Jan

As various "move memory back and forth between domains"
solutions are becoming increasingly fashionable, use
of order>0 allocations remains a ticking timebomb.

Does it make sense then now to somehow "deprecate" the
code in the allocator that allows order>0 allocations?
Not quite sure how, so just brainstorming.  Some ideas:

1) At minimum, a very big comment warning about the
   silent pitfalls due to fragmentation and a WARN_ON_ONCE
   that occurs when order>1 and debug=1 (and for xen-unstable).
2) Add a new routine for order>0 allocations (with
   a WARN_ON and a big comment) and BUG_ON order>0
   allocations attempted via the old interface.

IIRC, last I heard, some of the PCI-passthrough code
still uses order>0 allocations, so this (and any
other remaining culprits) might need to be grandfathered
in somehow.

But it would be nice to guarantee that new code isn't
allowed to make matters worse.

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