From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: RE: Tmem vs order>0 allocation, workaround RFC Date: Tue, 16 Feb 2010 13:20:50 -0500 Message-ID: <20100216182050.GE21067@phenom.dumpdata.com> References: <2af13319-6b44-44e2-ab62-a0615208cf64@default> <78c49794-4454-4c3b-80a6-72efcbc73fb3@default> <78c49794-4454-4c3b-80a6-72efcbc73fb3@default> <057c0f45-9c97-4b8a-8efa-1726fd951e19@default4B7A6363020000780002F93C@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: 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, Andrew@rcsinet12.oracle.com, Grzegorz Milos , George Dunlap , kurt.hackel@oracle.com, Ian Pratt , Jan Beulich , Deegan , Patrick Colp , Keir Fraser , Tim@rcsinet12.oracle.com, Peace List-Id: xen-devel@lists.xenproject.org On Tue, Feb 16, 2010 at 07:05:48AM -0800, Dan Magenheimer wrote: > Hi Jan -- > > Thanks for thinking about this. > > > may not work well: When you have 1Tb, you'd reserve 8G, making Dom0 > > single-page-below-4G-allocations impossible (unless dom0_mem= was > > used) if I read the logic correctly. > > Good point. But tmem doesn't work very well at all if dom0_mem > isn't set as dom0 is hogging all the spare memory in the system > so only fallow memory reclaimed from selfballooning domains > can be used by tmem. > > Under what circumstances does dom0 require single-page-below-4G > allocations? Is it only for bounce buffers for PCI passthrough > of old devices with 32-bit addressing limitations? Or am I > missing a much more common case? (I think it's important to The software IO TLB is initialized unconditionally if no IOMMUs are found. This is a 64MB + 32Kb chunk of memory that is exchanged with Xen to make sure it is under the 32-bit mark. > enumerate and understand -- and document -- all special needs > of memory pages as Xen has been fairly careless/lucky with > fragmentation so far, but with all the memory optimization > technologies in 4.0, we need to root out all the cases.) > > Thanks, > Dan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel