From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752520AbcHKW3R (ORCPT ); Thu, 11 Aug 2016 18:29:17 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:25537 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbcHKW2U (ORCPT ); Thu, 11 Aug 2016 18:28:20 -0400 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com Date: Thu, 11 Aug 2016 09:00:27 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Frederic Weisbecker , Christoph Lameter , Chris Metcalf , Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Andrew Morton , Rik van Riel , Tejun Heo , Thomas Gleixner , Viresh Kumar , Catalin Marinas , Will Deacon , Andy Lutomirski , Daniel Lezcano , linux-doc@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: clocksource_watchdog causing scheduling of timers every second (was [v13] support "task_isolation" mode) Reply-To: paulmck@linux.vnet.ibm.com References: <1468529299-27929-1-git-send-email-cmetcalf@mellanox.com> <7a3f66f7-5011-7d59-2e0e-f57e4e42e6b6@mellanox.com> <20160810221656.GC19757@lerouge> <20160811084002.GV30192@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160811084002.GV30192@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16081122-0008-0000-0000-000005495DAA X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005579; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000181; SDB=6.00743365; UDB=6.00350032; IPR=6.00515913; BA=6.00004658; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012317; XFM=3.00000011; UTC=2016-08-11 22:28:17 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16081122-0009-0000-0000-00003A29ECDD Message-Id: <20160811160027.GV3482@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-11_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608110286 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 11, 2016 at 10:40:02AM +0200, Peter Zijlstra wrote: > On Thu, Aug 11, 2016 at 12:16:58AM +0200, Frederic Weisbecker wrote: > > I had similar issues, this seems to happen when the tsc is considered not reliable > > (which doesn't necessarily mean unstable. I think it has to do with some x86 CPU feature > > flag). > > Right, as per the other email, in general we cannot know/assume the TSC > to be working as intended :/ > > > IIRC, this _has_ to execute on all online CPUs because every TSCs of running CPUs > > are concerned. > > With modern Intel we could run it on one CPU per package I think, but at > the same time, too much in NOHZ_FULL assumes the TSC is indeed sane so > it doesn't make sense to me to keep the watchdog running, when it > triggers it would also have to kill all NOHZ_FULL stuff, which would > probably bring the entire machine down.. Well, you -could- force a very low priority CPU-bound task to run on all nohz_full CPUs. Not necessarily a good idea, but a relatively non-intrusive response to that particular error condition. Thanx, Paul > Arguably we should issue a boot time warning if NOHZ_FULL is configured > and the TSC watchdog is running. > > > I personally override that with passing the tsc=reliable kernel > > parameter. Of course use it at your own risk. > > Yes, that is (sadly) our only option. Manually assert our hardware is > solid under the intended workload and then manually disabling the > watchdog. >