Re: 答复: [外部邮件] Re: [PATCH] iommu: Downgrade print level for iommu group information

[Pranjal Shrivastava <praan@google.com>]

On Wed, Nov 27, 2024 at 12:37:38PM +0000, Robin Murphy wrote:
> On 27/11/2024 10:16 am, Pranjal Shrivastava wrote:
> > On Tue, Nov 26, 2024 at 12:09:03PM +0000, Li,Rongqing wrote:
> > > 
> > > > On 26/11/2024 7:23 am, Li RongQing wrote:
> > > > > This per device log is becoming longer with more and more PCI devices
> > > > > in system, which slows down the boot process due to the serializing
> > > > > nature of printk().
> > > > > 
> > > > > Downgrade dev_info() to dev_dbg() so it is still accessible for debug
> > > > > purposes.
> > > > 
> > > > Previously discussed 4 and a half years ago:
> > > > 
> > > > https://lore.kernel.org/linux-iommu/20200302154426.GC6540@8bytes.org/
> > > > 
> > 
> > Hmm.. I'm wondering if ratelimiting might help here?
> > We can define a rate_limit for the iommu subsystem that can be tuned
> > accordingly to control verbosity. We can keep the rate_limit to a min.
> > as we'd like and maintain it upstream and give users an option to tune
> > it as per their requirement.
> 
> No, this is not an issue of rate, and we're not going to reinvent some
> obscure IOMMU-API-specific version of loglevel just for this. These are at
> "info" level for good reason, so anyone who only cares about warnings or
> errors can already filter their console output to suit.
> 

Ack. Agreed.

> Debug enough "my device stops working after I enable the IOMMU" issues by
> email using only dmesg logs, and you might start to appreciate how often
> it's a case of scrolling way way back from the apparent error to see that
> the device was added to a *different* group than expected, or crucially,
> seeing the conspicuous *absence* of any message, because the IOMMU driver
> didn't believe it was responsible for that device in the first place.

Hmm.. I agree.

> 
> Thanks,
> Robin.
> 

Thanks,
Praan