linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, Michal Nazarewicz <mina86@mina86.com>,
	Michal Hocko <mhocko@kernel.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 11:41:11 +0100	[thread overview]
Message-ID: <1480675271.17003.50.camel@pengutronix.de> (raw)
In-Reply-To: <74234427-005f-609e-3f33-cdf9a739c1d2@suse.cz>

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.

Regards,
Lucas

> [1] http://marc.info/?l=linux-mm&m=148053714627617&w=2
> 
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> >  mm/page_alloc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 2b3bf6767d54..b2cfb4074f90 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7398,7 +7398,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
> >
> >  	/* Make sure the range is really isolated. */
> >  	if (test_pages_isolated(outer_start, end, false)) {
> > -		pr_info("%s: [%lx, %lx) PFNs busy\n",
> > +		pr_debug("%s: [%lx, %lx) PFNs busy\n",
> >  			__func__, outer_start, end);
> >  		ret = -EBUSY;
> >  		goto done;
> >
> 
> 


--
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 10:41 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 [this message]
2016-12-02 10:48     ` Michal Hocko
2016-12-02 10:57       ` Lucas Stach
2016-12-02 12:32         ` Michal Nazarewicz

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=1480675271.17003.50.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mhocko@kernel.org \
    --cc=mina86@mina86.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).