From: Dmitry Safonov <dima@arista.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: linux-kernel@vger.kernel.org, 0x7f454c46@gmail.com,
Alex Williamson <alex.williamson@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
iommu@lists.linux-foundation.org
Subject: Re: [PATCHv2 4/6] iommu/intel: Handle DMAR faults on workqueue
Date: Tue, 13 Feb 2018 17:38:53 +0000 [thread overview]
Message-ID: <1518543533.2849.25.camel@arista.com> (raw)
In-Reply-To: <20180213163542.tdqhazwfjgqk3zuu@8bytes.org>
On Tue, 2018-02-13 at 17:35 +0100, Joerg Roedel wrote:
> On Mon, Feb 12, 2018 at 04:48:23PM +0000, Dmitry Safonov wrote:
> > dmar_fault() reports/handles/cleans DMAR faults in a cycle one-by-
> > one.
> > The nuisance is that it's set as a irq handler and runs with
> > disabled
> > interrupts - which works OK if you have only a couple of DMAR
> > faults,
> > but becomes a problem if your intel iommu has a plenty of mappings.
>
> I don't think that a work-queue is the right solution here, it adds a
> long delay until the log is processed. During that delay, and with
> high
> fault rates the error log will overflow during that delay.
>
> Here is what I think you should do instead to fix the soft-lockups:
>
> First, unmask the fault reporting irq so that you will get subsequent
> irqs. Then:
>
> * For Primary Fault Reporting just cycle once through all
> supported fault recording registers.
>
> * For Advanced Fault Reporting, read start and end pointer of
> the log and process all entries.
>
> After that return from the fault handler and let the next irq handle
> additional faults that might have been recorded while the previous
> handler was running.
Ok, will re-do this way, thanks.
> And of course, ratelimiting the fault printouts is always a good
> idea.
--
Dima
next prev parent reply other threads:[~2018-02-13 17:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 16:48 [PATCHv2 0/6] iommu/intel: Handle DMAR faults in a wq Dmitry Safonov
2018-02-12 16:48 ` [PATCHv2 1/6] iommu/intel: Add __init for dmar_register_bus_notifier() Dmitry Safonov
2018-02-12 16:48 ` [PATCHv2 2/6] iommu/intel: Clean/document fault status flags Dmitry Safonov
2018-02-12 16:48 ` [PATCHv2 3/6] iommu/intel: Introduce clear_primary_faults() helper Dmitry Safonov
2018-02-12 16:48 ` [PATCHv2 4/6] iommu/intel: Handle DMAR faults on workqueue Dmitry Safonov
2018-02-13 16:35 ` Joerg Roedel
2018-02-13 17:38 ` Dmitry Safonov [this message]
2018-02-15 19:09 ` Dmitry Safonov
2018-02-12 16:48 ` [PATCHv2 5/6] iommu/intel: Rename dmar_fault() => dmar_serve_faults() Dmitry Safonov
2018-02-12 16:48 ` [PATCHv2 6/6] iommu/intel: Ratelimit each dmar fault printing Dmitry Safonov
2018-02-12 17:26 ` [PATCHv3 " Dmitry Safonov
2018-02-13 16:44 ` [PATCHv2 0/6] iommu/intel: Handle DMAR faults in a wq Joerg Roedel
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=1518543533.2849.25.camel@arista.com \
--to=dima@arista.com \
--cc=0x7f454c46@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox