Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1149521imm; Wed, 10 Oct 2018 09:50:10 -0700 (PDT) X-Google-Smtp-Source: ACcGV60X1DLEx++6tS2la8XEYyb4uOZNPZOclMOvKg5qBLQ6JBOQ/LywiIXrZfgDjuCg4HsCWPEr X-Received: by 2002:a63:7d2:: with SMTP id 201-v6mr31038367pgh.129.1539190210180; Wed, 10 Oct 2018 09:50:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539190210; cv=none; d=google.com; s=arc-20160816; b=H30a+ZpaAJHonjhgZYv//kVI9ESmkByRRR8eDrtPLcXGGVYC9Q7/ce3XCvXB8A2l1a fHbJtb3nZuePsjk7qUGcnl+/1CDD0WHMWJeZBHzvHbIaLhjBunjnYzGejP6qKdeyVIm6 7rPKGPVtLdN9xNtj3X69fL/L8ibxjju6txLgahThIcIZwPBn2ShQrApFuhLZjwodTHVo +/1RKLFNI6+0bMF/P2pUTlwb6O31cFAPZtgr47SJtGfzKHmdGBChg+NOYd5urZqaRpV8 iWyHcAtRXbq1Tqh88eI3ojVaGnU9ux2fTifvsF+5lt1ypUSBaulv40EGgTwOrG9v8Obh q7cw== 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; bh=hol/fcaG2gCRByTXAbkKMFFDgdUNd4tywg+O9BeXlPo=; b=rPdUss1ah/o51mJmdLPU2trQiIX43HDokAN72HgxPYSmwkWDOLotJKdAXBQdMG1Q1x CC8qBvI2bwBP4gB3Vv2gzLf/7mofErS9AUT1QRBwhCHVhyMmV2x5d6AXu75P3eX7Q9c8 0n905nCRgpDcDFqohUMgYBIEnYf4jNbElWRFC1rbBKX3Ilo04Oy9P9GDyTiiswFb7D3Y wYPt1qd1ldGMAUS2rmzinGms+wkR1YlklQIFnAfGjeoGZ/1OLh6J2itVmvCNr8kDTGhh FfceWL0a/U8BpG045SUXqwinNkKD7DnyXcbPcm9gdcn2wK8vCz/BRLpFG1GWQO8ThAE+ bAhw== ARC-Authentication-Results: i=1; mx.google.com; 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 b2-v6si28166741plm.25.2018.10.10.09.49.54; Wed, 10 Oct 2018 09:50:10 -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; 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 S1726873AbeJKAMT (ORCPT + 99 others); Wed, 10 Oct 2018 20:12:19 -0400 Received: from foss.arm.com ([217.140.101.70]:55312 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726656AbeJKAMT (ORCPT ); Wed, 10 Oct 2018 20:12:19 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7DCC2ED1; Wed, 10 Oct 2018 09:49:20 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 423C83F5B3; Wed, 10 Oct 2018 09:49:20 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id F3F841AE088A; Wed, 10 Oct 2018 17:49:19 +0100 (BST) Date: Wed, 10 Oct 2018 17:49:19 +0100 From: Will Deacon To: Sodagudi Prasad Cc: catalin.marinas@arm.com, gregkh@linuxfoundation.org, ard.biesheuvel@linaro.org, robin.murphy@arm.com, ynorov@caviumnetworks.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: livelock with hrtimer cpu_base->lock Message-ID: <20181010164919.GA16512@arm.com> References: <8f671ebb6b331cd00ce17d111f28c548@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f671ebb6b331cd00ce17d111f28c548@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Prasad, On Tue, Oct 09, 2018 at 01:56:14PM -0700, Sodagudi Prasad wrote: > This is regarding - thread "try to fix contention between expire_timers and > try_to_del_timer_sync". > https://lkml.org/lkml/2017/7/28/172 > > I think this live lockup issue was discussed earlier but the final set of > changes were not concluded. Well we basically need a way to pick a value for CPU_RELAX_WFE_THRESHOLD. Do you have any ideas? It could be determined at runtime if necessary. > I would like to check whether you have new updates on this issue or not. > This problem is observed with 4.14 .64 stable kernel too. > We see this problem 2 times in overnight testing. > > I have to add the following code to avoid live lock. I am thinking that > fixing this at the cpu_relax() level. > > +++ b/kernel/time/hrtimer.c > @@ -52,6 +52,7 @@ > #include > #include > #include > +#include > > #include > > @@ -152,6 +153,7 @@ struct hrtimer_clock_base *lock_hrtimer_base(const > struct hrtimer *timer, > raw_spin_unlock_irqrestore(&base->cpu_base->lock, *flags); > } > cpu_relax(); > + udelay(1); > } > } > > @@ -1067,6 +1069,7 @@ int hrtimer_cancel(struct hrtimer *timer) > if (ret >= 0) > return ret; > cpu_relax(); > + udelay(1); > } > } > EXPORT_SYMBOL_GPL(hrtimer_cancel); This is just another bodge and likely to hurt in places where 1us is excessive because there isn't contention. Will