From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stephen C. Tweedie" Subject: Re: 3.0.2-testing: pci_set_dma_mask, pci_set_consistent_dma_mask(pci, 0x0fffffff) returns < 0 (ICE1712) Date: Wed, 12 Apr 2006 14:53:54 -0400 Message-ID: <1144868035.3337.63.camel@orbit.scot.redhat.com> References: <7c04185361beb49c8f09d80dc16d3e32@cl.cam.ac.uk> <1144862119.3337.35.camel@orbit.scot.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: 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: Keir Fraser Cc: Ian Pratt , xen-devel@lists.xensource.com, Tom Hibbert List-Id: xen-devel@lists.xenproject.org Hi, On Wed, 2006-04-12 at 18:19 +0100, Keir Fraser wrote: > > Are there plans to extend it to allow targeted freeing of memory in > > specific physical regions? That would improve the ability to support > > odd dma masks, but would also directly improve other things like the > > pgd > > starvation issue that we're currently working around with the > > lowmem_emergency_pool. It would be good to have a generic approach to > > that which did not require custom boot parameters. > > I'm not sure what you mean. Can you give a simple example? On raw metal, when we start to get low on a specific memory zone, either for DMA24/DMA32 or on a specific NUMA node, we can start to specifically reclaim pages from that memory zone, swapping them out or simply evicting cache. If the Xen HV runs out of MEMZONE_DMADOM pages, aren't we basically out of luck right now? Xen guests can't see that shortage, nor does the vmscan.c code have any code to target pages for stealing based on MFN rather than PFN. --Stephen