Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Jon Pan-Doh <pandoh@google.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Karolina Stolarek" <karolina.stolarek@oracle.com>,
	linux-pci@vger.kernel.org,
	"Martin Petersen" <martin.petersen@oracle.com>,
	"Ben Fuller" <ben.fuller@oracle.com>,
	"Drew Walton" <drewwalton@microsoft.com>,
	"Anil Agrawal" <anilagrawal@meta.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	"Terry Bowman" <Terry.bowman@amd.com>
Subject: Re: [PATCH v4 5/7] PCI/AER: Introduce ratelimit for error logs
Date: Fri, 21 Mar 2025 14:47:36 -0700	[thread overview]
Message-ID: <bfd75767-7743-47d7-939e-f0c5204ee647@linux.intel.com> (raw)
In-Reply-To: <CAMC_AXW6QgDV9bSiYR5UpgSAii+YSPLk_xCdYHZGjudDZpGstQ@mail.gmail.com>

Hi Jon,

On 3/21/25 12:24 PM, Jon Pan-Doh wrote:
> On Thu, Mar 20, 2025 at 6:00 PM Sathyanarayanan Kuppuswamy
> <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
>> Should we exclude fatal errors from the rate limit? Fatal error logs
>> would be
>> really useful for debug analysis, and they not happen very frequently.
> The logs today only make the distinction between correctable vs.
> uncorrectable so I thought it made sense to be consistent.

You're right. From a logging perspective, the current driver only
differentiates between correctable and uncorrectable errors. However,
the goal of your patch series is to reduce the spam of frequent errors.
While we are rate-limiting these frequent logs, we must ensure that we
don't miss important logs. I believe we did not rate-limit DPC logs for
this very reason.


>
> Maybe this is something that could be deferred? The only fixed

I am fine with deferring. IIUC, if needed, through sysfs user can
skip rate-limit for uncorrectable errors, right?

But, is the required change to do this complex? Won't skipping the
rate limit check for fatal errors solve the problem?

Bjorn, any comments? Do you think Fatal errors should be
rate-limited?

> component is the sysfs attribute names (which can be made to refer to
> uncorrectable nonfatal vs. uncorrectable in doc/underlying
> implementation).
>
> Thanks,
> Jon

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer


  reply	other threads:[~2025-03-21 21:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20  8:20 [PATCH v4 0/7] Rate limit AER logs Jon Pan-Doh
2025-03-20  8:20 ` [PATCH v4 1/7] PCI/AER: Check log level once and propagate down Jon Pan-Doh
2025-03-20  8:20 ` [PATCH v4 2/7] PCI/AER: Make all pci_print_aer() log levels depend on error type Jon Pan-Doh
2025-03-20  8:20 ` [PATCH v4 3/7] PCI/AER: Move AER stat collection out of __aer_print_error() Jon Pan-Doh
2025-03-20 14:59   ` Karolina Stolarek
2025-03-20 19:07     ` Jon Pan-Doh
2025-03-20  8:20 ` [PATCH v4 4/7] PCI/AER: Rename struct aer_stats to aer_report Jon Pan-Doh
2025-03-20 17:42   ` Sathyanarayanan Kuppuswamy
2025-03-20 19:53     ` Jon Pan-Doh
2025-03-21 13:38       ` Karolina Stolarek
2025-03-20  8:20 ` [PATCH v4 5/7] PCI/AER: Introduce ratelimit for error logs Jon Pan-Doh
2025-03-20 14:56   ` Karolina Stolarek
2025-03-20 17:51     ` Bjorn Helgaas
2025-03-20 19:53       ` Jon Pan-Doh
2025-03-20 20:29         ` Bjorn Helgaas
2025-03-21  1:58           ` Jon Pan-Doh
2025-03-20 19:37     ` Jon Pan-Doh
2025-03-21  1:00   ` Sathyanarayanan Kuppuswamy
2025-03-21 19:24     ` Jon Pan-Doh
2025-03-21 21:47       ` Sathyanarayanan Kuppuswamy [this message]
2025-03-21 21:59         ` Bjorn Helgaas
2025-03-21 22:11         ` Jon Pan-Doh
2025-03-20  8:20 ` [PATCH v4 6/7] PCI/AER: Add ratelimits to PCI AER Documentation Jon Pan-Doh
2025-03-20 14:57   ` Karolina Stolarek
2025-03-21  1:00   ` Sathyanarayanan Kuppuswamy
2025-03-20  8:20 ` [PATCH v4 7/7] PCI/AER: Add sysfs attributes for log ratelimits Jon Pan-Doh
2025-03-20 14:58   ` Karolina Stolarek
2025-03-20 19:36     ` Jon Pan-Doh
2025-03-21  1:02   ` Sathyanarayanan Kuppuswamy
2025-03-21  1:55     ` Jon Pan-Doh
2025-03-20 14:34 ` [PATCH v4 0/7] Rate limit AER logs Christoph Hellwig
2025-03-20 18:45 ` Paul E. McKenney

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=bfd75767-7743-47d7-939e-f0c5204ee647@linux.intel.com \
    --to=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Terry.bowman@amd.com \
    --cc=anilagrawal@meta.com \
    --cc=ben.fuller@oracle.com \
    --cc=bhelgaas@google.com \
    --cc=drewwalton@microsoft.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=karolina.stolarek@oracle.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=martin.petersen@oracle.com \
    --cc=pandoh@google.com \
    --cc=tony.luck@intel.com \
    /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