All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Lucas Stach <l.stach@pengutronix.de>, Michal Hocko <mhocko@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	linux-mm@kvack.org, "Robin H. Johnson" <robbat2@gentoo.org>,
	kernel@pengutronix.de, Andrew Morton <akpm@linux-foundation.org>,
	patchwork-lst@pengutronix.de,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH] mm: alloc_contig: demote PFN busy message to debug level
Date: Fri, 02 Dec 2016 13:32:13 +0100	[thread overview]
Message-ID: <xa1tfum6v7ea.fsf@mina86.com> (raw)
In-Reply-To: <1480676263.17003.55.camel@pengutronix.de>

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

      reply	other threads:[~2016-12-02 12:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02  9:57 [PATCH] mm: alloc_contig: demote PFN busy message to debug level Lucas Stach
2016-12-02 10:18 ` Vlastimil Babka
2016-12-02 10:41   ` Lucas Stach
2016-12-02 10:48     ` Michal Hocko
2016-12-02 10:57       ` Lucas Stach
2016-12-02 12:32         ` Michal Nazarewicz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xa1tfum6v7ea.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mhocko@suse.com \
    --cc=patchwork-lst@pengutronix.de \
    --cc=robbat2@gentoo.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.