Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

2018-03-29 9:50 GMT+01:00 Joerg Roedel : > On Tue, Mar 20, 2018 at 08:50:13PM +, Dmitry Safonov wrote: >> Hmm, but this fixes my softlockup issue, because it's about time spent >> in printk() inside irq-disabled section, rather about exiting the dmar- >> clearing loop. >> And

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

2018-03-29 9:50 GMT+01:00 Joerg Roedel : > On Tue, Mar 20, 2018 at 08:50:13PM +, Dmitry Safonov wrote: >> Hmm, but this fixes my softlockup issue, because it's about time spent >> in printk() inside irq-disabled section, rather about exiting the dmar- >> clearing loop. >> And on my hw doesn't

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Tue, Mar 20, 2018 at 08:50:13PM +, Dmitry Safonov wrote: > Hmm, but this fixes my softlockup issue, because it's about time spent > in printk() inside irq-disabled section, rather about exiting the dmar- > clearing loop. > And on my hw doesn't make any difference to limit loop or not

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Tue, Mar 20, 2018 at 08:50:13PM +, Dmitry Safonov wrote: > Hmm, but this fixes my softlockup issue, because it's about time spent > in printk() inside irq-disabled section, rather about exiting the dmar- > clearing loop. > And on my hw doesn't make any difference to limit loop or not

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > > But even with loop-limit we will need ratelimit each printk() > > *also*. > > Otherwise loop-limit will be based on time spent printing, not on > > anything else.. > > The

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > > But even with loop-limit we will need ratelimit each printk() > > *also*. > > Otherwise loop-limit will be based on time spent printing, not on > > anything else.. > > The

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > > But even with loop-limit we will need ratelimit each printk() > > *also*. > > Otherwise loop-limit will be based on time spent printing, not on > > anything else.. > > The

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > > But even with loop-limit we will need ratelimit each printk() > > *also*. > > Otherwise loop-limit will be based on time spent printing, not on > > anything else.. > > The

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > But even with loop-limit we will need ratelimit each printk() *also*. > Otherwise loop-limit will be based on time spent printing, not on > anything else.. > The patch makes sense even with loop-limit in my opinion. Looks like I

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > But even with loop-limit we will need ratelimit each printk() *also*. > Otherwise loop-limit will be based on time spent printing, not on > anything else.. > The patch makes sense even with loop-limit in my opinion. Looks like I

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 14:34 +, Dmitry Safonov wrote: > On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote: > > On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > > > So, you suggest to remove ratelimit at all? > > > Do we really need printk flood for each happened fault? > >

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 14:34 +, Dmitry Safonov wrote: > On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote: > > On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > > > So, you suggest to remove ratelimit at all? > > > Do we really need printk flood for each happened fault? > >

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > > So, you suggest to remove ratelimit at all? > > Do we really need printk flood for each happened fault? > > Imagine, you've hundreds of mappings and then PCI link flapped..

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > > So, you suggest to remove ratelimit at all? > > Do we really need printk flood for each happened fault? > > Imagine, you've hundreds of mappings and then PCI link flapped..

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > So, you suggest to remove ratelimit at all? > Do we really need printk flood for each happened fault? > Imagine, you've hundreds of mappings and then PCI link flapped.. > Wouldn't it be better to keep ratelimiting? > I don't mind,

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > So, you suggest to remove ratelimit at all? > Do we really need printk flood for each happened fault? > Imagine, you've hundreds of mappings and then PCI link flapped.. > Wouldn't it be better to keep ratelimiting? > I don't mind,

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 14:46 +0100, Joerg Roedel wrote: > On Thu, Feb 15, 2018 at 07:17:29PM +, Dmitry Safonov wrote: > > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > > index accf58388bdb..6c4ea32ee6a9 100644 > > --- a/drivers/iommu/dmar.c > > +++ b/drivers/iommu/dmar.c > > @@

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 14:46 +0100, Joerg Roedel wrote: > On Thu, Feb 15, 2018 at 07:17:29PM +, Dmitry Safonov wrote: > > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > > index accf58388bdb..6c4ea32ee6a9 100644 > > --- a/drivers/iommu/dmar.c > > +++ b/drivers/iommu/dmar.c > > @@

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Feb 15, 2018 at 07:17:29PM +, Dmitry Safonov wrote: > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > index accf58388bdb..6c4ea32ee6a9 100644 > --- a/drivers/iommu/dmar.c > +++ b/drivers/iommu/dmar.c > @@ -1618,17 +1618,13 @@ irqreturn_t dmar_fault(int irq, void *dev_id) >

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Feb 15, 2018 at 07:17:29PM +, Dmitry Safonov wrote: > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > index accf58388bdb..6c4ea32ee6a9 100644 > --- a/drivers/iommu/dmar.c > +++ b/drivers/iommu/dmar.c > @@ -1618,17 +1618,13 @@ irqreturn_t dmar_fault(int irq, void *dev_id) >

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

Gentle ping? On Mon, 2018-03-05 at 15:00 +, Dmitry Safonov wrote: > Hi Joerg, > > What do you think about v3? > It looks like, I can solve my softlookups with just a bit more proper > ratelimiting.. > > On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote: > > There is a ratelimit for

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

Gentle ping? On Mon, 2018-03-05 at 15:00 +, Dmitry Safonov wrote: > Hi Joerg, > > What do you think about v3? > It looks like, I can solve my softlookups with just a bit more proper > ratelimiting.. > > On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote: > > There is a ratelimit for

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

Hi Joerg, What do you think about v3? It looks like, I can solve my softlookups with just a bit more proper ratelimiting.. On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote: > There is a ratelimit for printing, but it's incremented each time the > cpu recives dmar fault interrupt. While

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

Hi Joerg, What do you think about v3? It looks like, I can solve my softlookups with just a bit more proper ratelimiting.. On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote: > There is a ratelimit for printing, but it's incremented each time the > cpu recives dmar fault interrupt. While

[PATCHv3] iommu/intel: Ratelimit each dmar fault printing

There is a ratelimit for printing, but it's incremented each time the cpu recives dmar fault interrupt. While one interrupt may signal about *many* faults. So, measuring the impact it turns out that reading/clearing one fault takes < 1 usec, and printing info about the fault takes ~170 msec.

[PATCHv3] iommu/intel: Ratelimit each dmar fault printing

There is a ratelimit for printing, but it's incremented each time the cpu recives dmar fault interrupt. While one interrupt may signal about *many* faults. So, measuring the impact it turns out that reading/clearing one fault takes < 1 usec, and printing info about the fault takes ~170 msec.