Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965209AbeAJOWF (ORCPT + 1 other); Wed, 10 Jan 2018 09:22:05 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:35736 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965113AbeAJOWD (ORCPT ); Wed, 10 Jan 2018 09:22:03 -0500 X-Google-Smtp-Source: ACJfBou2czw4y3SoZ6OlxlkTnxTvx9Ng704hP8QrEwmjJS7ySq1Z5jdSiRde/jT7rlzkFRitnBHd+g== Date: Wed, 10 Jan 2018 15:21:58 +0100 From: Juri Lelli To: "Rafael J. Wysocki" Cc: Leonard Crestez , Patrick Bellasi , Viresh Kumar , Linux PM , Anson Huang , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Vincent Guittot Subject: Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads Message-ID: <20180110142158.GC16413@localhost.localdomain> References: <20180108040121.GB4003@vireshk-i7> <1515417622.3207.5.camel@nxp.com> <20180108151450.GA30937@e110439-lin> <1515426694.3207.28.camel@nxp.com> <1515508985.3310.8.camel@nxp.com> <20180110105451.GB16413@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 10/01/18 13:35, Rafael J. Wysocki wrote: > On Wed, Jan 10, 2018 at 11:54 AM, Juri Lelli wrote: > > On 09/01/18 16:50, Rafael J. Wysocki wrote: > >> On Tue, Jan 9, 2018 at 3:43 PM, Leonard Crestez wrote: > > > > [...] > > > >> > Every 4 seconds (really it's /proc/sys/kernel/watchdog_thresh * 2 / 5 > >> > and watchdog_thresh defaults to 10). There is a per-cpu hrtimer which > >> > wakes the per-cpu thread in order to check that tasks can still > >> > execute, this works very well against bugs like infinite loops in > >> > softirq mode. The timers are synchronized initially but can get > >> > staggered (for example by hotplug). > >> > > >> > My guess is that it's only marked RT so that it executes ahead of other > >> > threads and the watchdog doesn't trigger simply when there are lots of > >> > userspace tasks. > >> > >> I think so too. > >> > >> I see a couple of more-or-less hackish ways to avoid the issue, but > >> nothing particularly attractive ATM. > >> > >> I wouldn't change the general behavior with respect to RT tasks > >> because of this, though, as we would quickly find a case in which that > >> would turn out to be not desirable. > > > > I agree we cannot generalize to all RT tasks, but what Patrick proposed > > (clamping utilization of certain known tasks) might help here: > > > > lkml.kernel.org/r/20170824180857.32103-1-patrick.bellasi@arm.com > > > > Maybe with a per-task interface instead of using cgroups? > > The problem here is that this is a kernel thing and user space should > not be expected to have to do anything about fixing this IMO. Not sure. If we would have such an interface, it should be possible to use it from both kernel and userspace. In this case kernel might be able to do the "right" thing. Also, RT userspace is usually already responsible for configuring system priorities, it might be easy to set this as well. > > The other option would be to relax DL tasks affinity constraints, so > > that a case like this might be handled. Daniel and Tommaso proposed > > possible approaches, this might be a driving use case. Not sure how we > > would come up with a proper runtime for the watchdog, though. > > That is a problem. > > Basically, it needs to run as soon as possible, but it will be running > for a very short time, every time. Does it really require to run "as soon as possible" or is it "at least once every watchdog period"? In the latter case DL might still fit, with a very short runtime (to be defined). > Overall, using a thread for that seems wasteful ... Not sure I'm following you here, aren't we using a thread already? Thanks, - Juri