Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752114AbdIEPmm (ORCPT ); Tue, 5 Sep 2017 11:42:42 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:46144 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752064AbdIEPmi (ORCPT ); Tue, 5 Sep 2017 11:42:38 -0400 Date: Tue, 5 Sep 2017 17:42:32 +0200 (CEST) From: Thomas Gleixner To: Don Zickus cc: Peter Zijlstra , Ulrich Obergfell , LKML , Ingo Molnar , Andrew Morton , Borislav Petkov , Sebastian Siewior , Nicholas Piggin , Chris Metcalf Subject: Re: [patch 11/29] lockup_detector: Remove park_in_progress hackery In-Reply-To: <20170905151531.4rw3e4ab5qpamstz@redhat.com> Message-ID: References: <20170831071558.995235362@linutronix.de> <20170831073053.863251887@linutronix.de> <20170904121050.dsqbh3efmkteu3qj@hirez.programming.kicks-ass.net> <20170905151531.4rw3e4ab5qpamstz@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1471 Lines: 37 On Tue, 5 Sep 2017, Don Zickus wrote: > On Mon, Sep 04, 2017 at 02:10:50PM +0200, Peter Zijlstra wrote: > > On Mon, Sep 04, 2017 at 01:09:06PM +0200, Ulrich Obergfell wrote: > > > > > - A thread hogs CPU N (soft lockup) so that watchdog/N is unable to run. > > > - A user re-configures 'watchdog_thresh' on the fly. The reconfiguration > > > requires parking/unparking of all watchdog threads. > > > > This is where you fail, its silly to require parking for > > reconfiguration. > > Hi Peter, > > Ok, please elaborate. Unless I am misunderstanding, that is what Thomas > requested us do years ago when he implemented the parking/unparking scheme > and what his current patch set is doing now. > > The point of parking I believe was to avoid the overhead of tearing down a > thread and restarting it when the code needed to update various lockup > detector settings. > > So if we can't depend on parking for reconfiguration, then are the other > options (besides tearing down threads)? Yes, the park/unpark is what I still use as this was the simplest way to keep everything in sync. I pondered to do on the fly reconfiguration as well, but that would add more code and would not solve the general issue of park/unpark. So I rather went for a single mechanism which just works, even if it is suboptimal cpu cycle wise. OTOH that reconfiguration is not something which happens every 5ms, so we can just go for the stupid, but simple mechanism. Thanks, tglx