On Fri 02-12-16 11:41:11, Lucas Stach wrote: > Am Freitag, den 02.12.2016, 11:18 +0100 schrieb Vlastimil Babka: > > On 12/02/2016 10:57 AM, Lucas Stach wrote: > > > There are a lot of reasons why a PFN might be busy and unable to be isolated > > > some of which can't really be avoided. This message is spamming the logs when > > > a lot of CMA allocations are happening, causing isolation to happen quite > > > frequently. > > > > Is this related to Robin's report [1] or you have an independent case of > > lots of CMA allocations, and in which context are there? > > > No, I've seen this bug report, but this patch was sitting to be sent out > for a while now. > > > > Demote the message to log level, as CMA will just retry the allocation, so > > > there is no need to have this message in the logs. If someone is interested > > > in the failing case, there is a tracepoint to track those failures properly. > > > > I don't think we should just hide the issue like this, as getting high > > volume reports from this is also very likely associated with high > > overhead for the allocations. If it's the generic dma-cma context, like > > in [1] where it attempts CMA for order-0 allocations, we should first do > > something about that, before tweaking the logging. > > > Etnaviv (the driver I maintain) currently does a stupid thing by > allocating and freeing lots of DMA buffers (higher-order) from different > threads. This is causing overhead at the CMA side, but really isn't > something to be handled at the CMA side, but rather Etnaviv must get > more clever about its CMA usage. > > Still this message is really disturbing as page isolation failures can > be caused by lots of other reasons like temporarily pinned pages. Hmm, then I think that what Robin has proposed [1] should be a generally better solution because it both ratelimits and points to the user who is triggering this path. I am still not really sure I understand why is the message useful, to be honest so it very well might be better to just remove it altogether. This is something for the CMA guys to answer though. [1] http://lkml.kernel.org/r/robbat2-20161130T195244-998539995Z@xxxxxxxxxxxxxxxxxx -- 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>