Re: drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy
From: Michal Hocko <mhocko@kernel.org>
Date: 2016-12-01 16:11:23
Also in:
dri-devel, lkml
On Thu 01-12-16 17:03:52, Michal Nazarewicz wrote:
On Thu, Dec 01 2016, Michal Hocko wrote:quoted
Let's also CC Marek On Thu 01-12-16 08:43:40, Vlastimil Babka wrote:quoted
On 12/01/2016 08:21 AM, Michal Hocko wrote:quoted
Forgot to CC Joonsoo. The email thread starts more or less here http://lkml.kernel.org/r/20161130092239.GD18437@dhcp22.suse.cz On Thu 01-12-16 08:15:07, Michal Hocko wrote:quoted
On Wed 30-11-16 20:19:03, Robin H. Johnson wrote: [...]quoted
alloc_contig_range: [83f2a3, 83f2a4) PFNs busyHuh, do I get it right that the request was for a _single_ page? Why do we need CMA for that?Ugh, good point. I assumed that was just the PFNs that it failed to migrate away, but it seems that's indeed the whole requested range. Yeah sounds some part of the dma-cma chain could be smarter and attempt CMA only for e.g. costly orders.Is there any reason why the DMA api doesn't try the page allocator first before falling back to the CMA? I simply have a hard time to see why the CMA should be used (and fragment) for small requests size.There actually may be reasons to always go with CMA even if small regions are requested. CMA areas may be defined to map to particular physical addresses and given device may require allocations from those addresses. This may be more than just a matter of DMA address space. I cannot give you specific examples though and I might be talking nonsense.
I am not familiar with this code so I cannot really argue but a quick look at rmem_cma_setup doesn't suggest any speicific placing or anything... -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>