Received: by 10.223.185.116 with SMTP id b49csp4180457wrg; Mon, 26 Feb 2018 12:40:44 -0800 (PST) X-Google-Smtp-Source: AH8x225dA01wNz+/EGPQfYawVmm7BKkyPin9KP3dH2g3srsK47b2YkN5dnqgJvu22UR4hpDsPt/z X-Received: by 10.99.124.68 with SMTP id l4mr9370382pgn.225.1519677644119; Mon, 26 Feb 2018 12:40:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519677644; cv=none; d=google.com; s=arc-20160816; b=N34p9IYZi0FHERcOchEfhGV8Ol2BCPNrAcSCVTFa2zlIoMhOrwnBuvwuDsQdarfeqo EHjKKkAeqQOv9OYkbZE433fh9xK2jbnvBrN8AAajV7U+obZHxiZQRYfMoYGXZgkjkWvk y9uAyyi3VPsA+oFImdqEU592hicxIcOCHtc5lbw3nw8SU38ZnFo4Gsd4/atb/XnzihSt CF96Cuo3J7V5ScXVQ0Vlmehl2+L9ZwC1h1U4N+4kEN3cJCZvU0OHGkNSpSnNHh9XIs7O qBaMTaP0e7YHG+11xUVLY8Qbcsvu7NkOsIMb9hc/Fh5lmB/kSyEFS+/BhUDpik//ngUS LE4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=lj5Lt0qvfZyBpsqIq7fLE3yUnm3f3+x1betHCDHAOmQ=; b=OFISdluykDxEEQbXGARfHrl4shSaRkAIlkj5avbK9JWOIEm3zB+HJ2HQonEQ2uORZE sxiuLuDr2ND4g4x5tdBVsvqR0KzScs9qCx/JpaxV8NA2jY/ugOXVGYb7XhZSUbvkN8Og yi9TBV4T8qNoUqZHcfjiOgEp+P1l2D0DYrnGv8Yo658JvSIN2TLMIBOXtQbu0xFvNB51 O1H3NAID6JMN1N1F5G8dBCYj7QtXO5k8YwS8lJiYYbaR2CGGbfQC94+YberKaSwRbgz/ KJLCwFSLaFEJnTAv2hoP+u/MbDwcw8PRrk7pc0YNzGY0akDTAjAmCLmT1b9lDokC87QW RMyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i2si5946293pgf.145.2018.02.26.12.40.28; Mon, 26 Feb 2018 12:40:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753005AbeBZUjy (ORCPT + 99 others); Mon, 26 Feb 2018 15:39:54 -0500 Received: from mga11.intel.com ([192.55.52.93]:37494 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbeBZUjw (ORCPT ); Mon, 26 Feb 2018 15:39:52 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 12:39:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,397,1515484800"; d="scan'208";a="178244350" Received: from akleen-mobl.amr.corp.intel.com (HELO tassilo.localdomain) ([10.7.201.133]) by orsmga004.jf.intel.com with ESMTP; 26 Feb 2018 12:39:51 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 0DC3E300FEA; Mon, 26 Feb 2018 12:39:37 -0800 (PST) Date: Mon, 26 Feb 2018 12:39:37 -0800 From: Andi Kleen To: Peter Zijlstra Cc: Cong Wang , "Liang, Kan" , jolsa@redhat.com, bigeasy@linutronix.de, "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , x86 , LKML Subject: Re: Long standing kernel warning: perfevents: irq loop stuck! Message-ID: <20180226203937.GA21543@tassilo.jf.intel.com> References: <20180223121456.GZ25201@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180223121456.GZ25201@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Given the HSD143 errata and its possible relevance, have you tried > changing the magic number to 32, does it then still fix things? > > No real objection to the patch as such, it just needs a coherent comment > and a tested-by tag I think. 128 min period will affect a lot of valid use cases with slower ticking events. I often use smaller periods there. It would be better to debug this properly. Or at a minimum only do the limitation for the events that tick really fast (like cycles, uops retired etc.) -Andi