Am Freitag, den 02.12.2016, 11:48 +0100 schrieb Michal Hocko: > 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. Dumping a stacktrace at this point is only going to increase the noise from this message, as it can be trigger under normal operating conditions of CMA. If someone temporarily locked a previously movable page with GUP or something alike, the stacktrace will point to the victim rather than the offender, so I think the value of the stackstrace is rather limited. Regards, Lucas -- 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>