On Thu 01-12-16 17:03:52, Michal Nazarewicz wrote: > On Thu, Dec 01 2016, Michal Hocko wrote: > > Let's also CC Marek > > > > On Thu 01-12-16 08:43:40, Vlastimil Babka wrote: > >> On 12/01/2016 08:21 AM, Michal Hocko wrote: > >> > Forgot to CC Joonsoo. The email thread starts more or less here > >> > http://lkml.kernel.org/r/20161130092239.GD18437@xxxxxxxxxxxxxx > >> > > >> > On Thu 01-12-16 08:15:07, Michal Hocko wrote: > >> > > On Wed 30-11-16 20:19:03, Robin H. Johnson wrote: > >> > > [...] > >> > > > alloc_contig_range: [83f2a3, 83f2a4) PFNs busy > >> > > > >> > > Huh, 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>