From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752497AbeCOOmF (ORCPT ); Thu, 15 Mar 2018 10:42:05 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:37690 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943AbeCOOmD (ORCPT ); Thu, 15 Mar 2018 10:42:03 -0400 X-Google-Smtp-Source: AG47ELtZynXOcUgYGxP1QMb2IVDMcWl7ON03d4ZWEgkVP/iqjZnDF33pvHpwVTLwMqXXq7mK3JpBNw== Message-ID: <1521124920.2686.20.camel@arista.com> Subject: Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing From: Dmitry Safonov To: Joerg Roedel Cc: linux-kernel@vger.kernel.org, 0x7f454c46@gmail.com, Alex Williamson , David Woodhouse , Ingo Molnar , Lu Baolu , iommu@lists.linux-foundation.org Date: Thu, 15 Mar 2018 14:42:00 +0000 In-Reply-To: <1521124490.2686.16.camel@arista.com> References: <20180215191729.15777-1-dima@arista.com> <20180315134649.skh2aukcmg5ud74y@8bytes.org> <1521123183.2686.7.camel@arista.com> <20180315142253.GC5259@8bytes.org> <1521124490.2686.16.camel@arista.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-03-15 at 14:34 +0000, Dmitry Safonov wrote: > On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote: > > On Thu, Mar 15, 2018 at 02:13:03PM +0000, 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, just it looks a bit strange to me. > > > > I never said you should remove the ratelimiting, after all you are > > trying to fix a soft-lockup, no? > > > > And that should not be fixed by changes to the ratelimiting, but > > with > > proper irq handling. > > Uh, I'm a bit confused then. > - Isn't it better to ratelimit each printk() instead of bunch of > printks inside irq handler? > - I can limit the number of loops, but the most of the time is spent > in > the loop on printk() (on my machine ~170msec per loop), while > everything else takes much lesser time (on my machine < 1 usec per > loop). So, if I will limit number of loops per-irq, that cycle-limit > will be based on limiting time spent on printk (e.g., how many > printks > to do in atomic context so that node will not lockup). It smells like > ratelimiting, no? > > I must be misunderstanding something, but why introducing another > limit > for number of printk() called when there is ratelimit which may be > tuned.. > So I agree, that maybe better to have another limit to the cycle *also*, because if we clean faults with the same speed as they're generated by hw, we may stuck in the loop.. By on my measures clearing fault is so fast (< 1 usec), that I'm not sure that it may happen with hw. By that reason I didn't introduce loop-limit. 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. -- Thanks, Dmitry