Re: [PATCH] mm: alloc_contig: demote PFN busy message to debug level

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> Am Freitag, den 02.12.2016, 11:18 +0100 schrieb Vlastimil Babka:
>>>> 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.

That was also my concern.  Ideally we would have a counter which
increments whenever isolation failure happens and some monitoring of
that counter but this is kernel so that’s just a pipe dream.

>> On Fri 02-12-16 11:41:11, Lucas Stach wrote:
>>> Still this message is really disturbing as page isolation failures can
>>> be caused by lots of other reasons like temporarily pinned pages.

Just so we’re on the same page, lots of allocations is not a *reason* of
isolation failures.  It only surfaces it.

This is not to disagree about better having code that is smart about
allocating DMA buffers.  This is true regardless.

> Am Freitag, den 02.12.2016, 11:48 +0100 schrieb Michal Hocko:
>> 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. 

On Fri, Dec 02 2016, Lucas Stach wrote:
> 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.

I agree, which is why I suggested printing the stack only if
CONFIG_CMA_DEBUG is enabled.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

--
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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]