Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3742938yba; Tue, 9 Apr 2019 04:01:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxyMVqbYaT2cnroFbTwM2NkSNbb8jWUQ0e42izZRlNevo+MDq+3/nZ15egWZ60epJvoFhIa X-Received: by 2002:a65:6210:: with SMTP id d16mr32992415pgv.110.1554807671573; Tue, 09 Apr 2019 04:01:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554807671; cv=none; d=google.com; s=arc-20160816; b=EjSYtpYpwmTUJPV8cymmTPqRKyMiCk6C2EIOyyZnFPfgeirGoE54095k7loqyw0T0i iZZA2UPZ+sAKv5cf9Vz6zpc8tfYeQMrSYO12nXMiAhYa1gylzOapNKWqiLJwBNb21U5P kxqanUmfWstHCQERW0POUnMfB3/ir0HDxuFkA7Eut4iZLtG86WDyM5BZ5NBXUqg6+ArE YPkfJPx0GMbogphKGhvujzD5qG9CiZ3eTpI0mAxiu4HL/4nkoN2pSXcPG13FLa59C5R/ CDeBRzsB5/eM8hi+3MpMYV/g7rRpoy1AcigfUjmAn+G7U30PPKusST9FMQIl7wYtI0Mi //+g== 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:dkim-signature; bh=4MNrtPReHgTdlubJ6RA99o6zlc1NcScJp4aN2SxpjRM=; b=wRzLPv+IgAQMGreBueLvBcriKP+uWvaTPwg2LFzALQ3NhN7LbuEcWVs/C6sBM+67e0 9i4Zuh94rtwKOV+cCkTnvTpd5hll0c5kDEDODvKiYLTe0sqV7v496CgXSpn+nF85eoHi yReLvWO5ND+jWhsqRRDVCXRNk3JncriKrONvtMdG49P/7r3J+8oJWoUhmdU6HtMdEvr/ NjMxbb615pmDvgia5GcQVPLiaLuiODv14cK2F0Gy6UTB3/2FuTKSURZe+HItsyk9W8w4 BnvxG52ugWJDlBVtFbEqXUWdvaRw/1HuFUc/C6i0PehVSE4pjoux9hoiFfppt+lBMzMm emrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=yDrh5wOv; 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 b10si28666980plr.131.2019.04.09.04.00.54; Tue, 09 Apr 2019 04:01:11 -0700 (PDT) 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; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=yDrh5wOv; 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 S1726615AbfDILAT (ORCPT + 99 others); Tue, 9 Apr 2019 07:00:19 -0400 Received: from merlin.infradead.org ([205.233.59.134]:41514 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726129AbfDILAS (ORCPT ); Tue, 9 Apr 2019 07:00:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4MNrtPReHgTdlubJ6RA99o6zlc1NcScJp4aN2SxpjRM=; b=yDrh5wOvwNF4zer2WsQ25BTsd uaogI5FDdrZHIXd7sRLAqNuz9gDk23hBAbxJWb/VSOjK2AjzGK1OBDT4VK0Vwko+XTJ6NDzN0ZdPV bPxehnFnM9Vi0huH31n3thYm5vwmqmU+leo7LaOeTDcz/Yz8BLiSdmAqUFK+52P9YZoKaMQIBAtNW KqN6APfWI3StV80XsFcBKPfVrsJDgvYvilOWmCv9FjokT/s+cuVZpPECA3VIY+jRv9t0mluHF88hP Apvgfu4CEvW1ZU6ErMObpdjj5xwoB0zi9wESJ4BOWdf1H2pTmV1n8fGHZPS3U1XThCIVDmCzHPelQ znFGQd+6A==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDoTk-0006Zp-Tu; Tue, 09 Apr 2019 10:59:49 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 4D90F201F29A4; Tue, 9 Apr 2019 12:59:46 +0200 (CEST) Date: Tue, 9 Apr 2019 12:59:46 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: Ricardo Neri , Ingo Molnar , Borislav Petkov , Ashok Raj , Andi Kleen , "Ravi V. Shankar" , x86@kernel.org, linux-kernel@vger.kernel.org, Ricardo Neri , "H. Peter Anvin" , Tony Luck , Clemens Ladisch , Arnd Bergmann , Philippe Ombredanne , Kate Stewart , "Rafael J. Wysocki" , Mimi Zohar , Jan Kiszka , Nick Desaulniers , Masahiro Yamada , Nayna Jain Subject: Re: [RFC PATCH v2 11/14] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector Message-ID: <20190409105946.GR4038@hirez.programming.kicks-ass.net> References: <1551283518-18922-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1551283518-18922-12-git-send-email-ricardo.neri-calderon@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 26, 2019 at 09:49:13PM +0100, Thomas Gleixner wrote: > So way you should handle this is: > > cpumask_set_cpu(cpu, hld_data->cpu_monitored_mask); > > if (!hld_data->enabled_cpus++) { > hld_data->handling_cpu = cpu; > kick_timer(); > enable_timer(); > } > > The cpu mask starts off empty and each CPU sets itself when the function is > invoked on it. > > data->enabled_cpus keeps track of the enabled cpus so you avoid > reconfiguration just because a different cpu comes online. And it's > required for disable as well. > > > +void hardlockup_detector_hpet_disable(void) > > +{ > > + struct cpumask *allowed = watchdog_get_allowed_cpumask(); > > + > > + if (!hld_data) > > + return; > > + > > + /* Only disable the timer if there are no more CPUs to monitor. */ > > + if (!cpumask_weight(allowed)) > > + disable_timer(hld_data); > > Again this should be: > > cpumask_clear_cpu(cpu, hld_data->cpu_monitored_mask); > hld_data->enabled_cpus--; > > if (hld_data->handling_cpu != cpu) > return; > > disable_timer(); > if (hld_data->enabled_cpus) > return; if (!hld_data->enabled_cpus) return; > > hld_data->handling_cpu = cpumask_first(hld_data->cpu_monitored_mask); > enable_timer(); That said; you can do the above without ->enabled_cpus, by using ->handling_cpu == nr_cpu_ids to indicate 'empty'. But I'm not at all sure that is worth the effort, it results in less obious code.