All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qian Cai <cai@lca.pw>
To: Joe Perches <joe@perches.com>, jroedel@suse.de
Cc: iommu@lists.linux-foundation.org, dwmw2@infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] iommu/iova: silence warnings under memory pressure
Date: Fri, 22 Nov 2019 09:59:20 -0500	[thread overview]
Message-ID: <1574434760.9585.18.camel@lca.pw> (raw)
In-Reply-To: <7fd08d481a372ea0b600f95c12166ab54ed5e267.camel@perches.com>

On Thu, 2019-11-21 at 20:37 -0800, Joe Perches wrote:
> On Thu, 2019-11-21 at 21:55 -0500, Qian Cai wrote:
> > When running heavy memory pressure workloads, this 5+ old system is
> > throwing endless warnings below because disk IO is too slow to recover
> > from swapping. Since the volume from alloc_iova_fast() could be large,
> > once it calls printk(), it will trigger disk IO (writing to the log
> > files) and pending softirqs which could cause an infinite loop and make
> > no progress for days by the ongoimng memory reclaim. This is the counter
> > part for Intel where the AMD part has already been merged. See the
> > commit 3d708895325b ("iommu/amd: Silence warnings under memory
> > pressure"). Since the allocation failure will be reported in
> > intel_alloc_iova(), so just call printk_ratelimted() there and silence
> > the one in alloc_iova_mem() to avoid the expensive warn_alloc().
> 
> []
> > v2: use dev_err_ratelimited() and improve the commit messages.
> 
> []
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> 
> []
> > @@ -3401,7 +3401,8 @@ static unsigned long intel_alloc_iova(struct device *dev,
> >  	iova_pfn = alloc_iova_fast(&domain->iovad, nrpages,
> >  				   IOVA_PFN(dma_mask), true);
> >  	if (unlikely(!iova_pfn)) {
> > -		dev_err(dev, "Allocating %ld-page iova failed", nrpages);
> > +		dev_err_ratelimited(dev, "Allocating %ld-page iova failed",
> > +				    nrpages);
> 
> Trivia:
> 
> This should really have a \n termination on the format string
> 
> 		dev_err_ratelimited(dev, "Allocating %ld-page iova failed\n",
> 
> 

Why do you say so? It is right now printing with a newline added anyway.

 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Qian Cai <cai@lca.pw>
To: Joe Perches <joe@perches.com>, jroedel@suse.de
Cc: baolu.lu@linux.intel.com, dwmw2@infradead.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] iommu/iova: silence warnings under memory pressure
Date: Fri, 22 Nov 2019 09:59:20 -0500	[thread overview]
Message-ID: <1574434760.9585.18.camel@lca.pw> (raw)
In-Reply-To: <7fd08d481a372ea0b600f95c12166ab54ed5e267.camel@perches.com>

On Thu, 2019-11-21 at 20:37 -0800, Joe Perches wrote:
> On Thu, 2019-11-21 at 21:55 -0500, Qian Cai wrote:
> > When running heavy memory pressure workloads, this 5+ old system is
> > throwing endless warnings below because disk IO is too slow to recover
> > from swapping. Since the volume from alloc_iova_fast() could be large,
> > once it calls printk(), it will trigger disk IO (writing to the log
> > files) and pending softirqs which could cause an infinite loop and make
> > no progress for days by the ongoimng memory reclaim. This is the counter
> > part for Intel where the AMD part has already been merged. See the
> > commit 3d708895325b ("iommu/amd: Silence warnings under memory
> > pressure"). Since the allocation failure will be reported in
> > intel_alloc_iova(), so just call printk_ratelimted() there and silence
> > the one in alloc_iova_mem() to avoid the expensive warn_alloc().
> 
> []
> > v2: use dev_err_ratelimited() and improve the commit messages.
> 
> []
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> 
> []
> > @@ -3401,7 +3401,8 @@ static unsigned long intel_alloc_iova(struct device *dev,
> >  	iova_pfn = alloc_iova_fast(&domain->iovad, nrpages,
> >  				   IOVA_PFN(dma_mask), true);
> >  	if (unlikely(!iova_pfn)) {
> > -		dev_err(dev, "Allocating %ld-page iova failed", nrpages);
> > +		dev_err_ratelimited(dev, "Allocating %ld-page iova failed",
> > +				    nrpages);
> 
> Trivia:
> 
> This should really have a \n termination on the format string
> 
> 		dev_err_ratelimited(dev, "Allocating %ld-page iova failed\n",
> 
> 

Why do you say so? It is right now printing with a newline added anyway.

 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
 hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed


  reply	other threads:[~2019-11-22 14:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22  2:55 [PATCH v2] iommu/iova: silence warnings under memory pressure Qian Cai
2019-11-22  2:55 ` Qian Cai
2019-11-22  4:37 ` Joe Perches
2019-11-22  4:37   ` Joe Perches
2019-11-22 14:59   ` Qian Cai [this message]
2019-11-22 14:59     ` Qian Cai
2019-11-22 16:28     ` Joe Perches
2019-11-22 16:28       ` Joe Perches
2019-11-22 16:46       ` Qian Cai
2019-11-22 16:46         ` Qian Cai
2019-11-22 16:49         ` Joe Perches
2019-11-22 16:49           ` Joe Perches

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=1574434760.9585.18.camel@lca.pw \
    --to=cai@lca.pw \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joe@perches.com \
    --cc=jroedel@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.