From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: [PATCH 0/6] x86: break up post-boot non-order-zero allocations Date: Wed, 06 Apr 2011 07:46:29 +0100 Message-ID: <4D9C2865020000780003A1D7@vpn.id2.novell.com> References: <4D9AECA60200007800039F26@vpn.id2.novell.com> <80f4b778-0b4d-490b-8ce9-3df37a01d029@default> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <80f4b778-0b4d-490b-8ce9-3df37a01d029@default> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> On 06.04.11 at 04:50, Dan Magenheimer = wrote: > IIRC, PCI-passthrough is another user of multi-page allocations. As noted in the description, with the intended solution being to switch from arrays to radix trees. Or do you know of other than the mentioned cases? > At some point, does it make sense to eliminate the multi-page > allocation functionality, at least through the "normal" > page allocation routines, and add a: >=20 > /* documentation about why not to use this */ > alloc_contiguous_pages_DEPRECATED(order) >=20 > call so that it is very explicit when future page allocation > users "regress" by adding a multi-page allocation request? I wouldn't go that far. Instead I was considering adding a (perhaps one-time) warning so that things wouldn't start outright failing, but remaining code paths get pointed out. But that ought to happen only once all known allocations have been dealt with. Jan