From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755381AbbLDICc (ORCPT ); Fri, 4 Dec 2015 03:02:32 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:38517 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542AbbLDICa (ORCPT ); Fri, 4 Dec 2015 03:02:30 -0500 Date: Fri, 4 Dec 2015 09:02:26 +0100 From: Ingo Molnar To: Tejun Heo Cc: Ulrich Obergfell , Don Zickus , Ingo Molnar , Peter Zijlstra , Andrew Morton , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 2/2] workqueue: implement lockup detector Message-ID: <20151204080226.GA25880@gmail.com> References: <20151203002810.GJ19878@mtj.duckdns.org> <20151203002839.GK19878@mtj.duckdns.org> <20151203175024.GE27730@redhat.com> <20151203194358.GK27463@mtj.duckdns.org> <1971916814.34665208.1449173540866.JavaMail.zimbra@redhat.com> <20151203205449.GL27463@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151203205449.GL27463@mtj.duckdns.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Tejun Heo wrote: > Hello, Ulrich. > > On Thu, Dec 03, 2015 at 03:12:20PM -0500, Ulrich Obergfell wrote: > > I share Don's concern about connecting the soft lockup detector and the > > workqueue watchdog to the same kernel parameter in /proc. I would feel > > more comfortable if the workqueue watchdog had its dedicated parameter. > > Sure, separating the knobs out isn't difficult. I still don't like > the idea of having multiple set of similar knobs controlling about the > same thing tho. > > For example, let's say there's a user who boots with "nosoftlockup" > explicitly. I'm pretty sure the user wouldn't be intending to keep > workqueue watchdog running. The same goes for threshold adjustments, > so here's my question. What are the reasons for the concern? What > are we worrying about? As Don mentioned it already, we went through similar arguments (and pain) with the hard/soft lockup detectors and its various control knobs, it would be better to have new control knobs separated. As for the ease of use argument, we can add a new, obviously named control knob that controls _all_ lockup detectors: boot param: nolockupdetectors matching Kconfig knob: CONFIG_BOOTPARAM_NO_LOCKUP_DETECTORS=0 but please don't artificially couple the control knobs of these various lockup detectors, as these internal assumptions are less than obvious to users. With (effectively) 4 lockup detectors such coupling of interfaces is even more confusing and damaging. but ease of use is not a big concern in any case, since new debug features are disabled by default, so only those people will see it (and may want to disable it via a boot parameter, hopefully only temporarily) who enable it intentionally. Thanks, Ingo