From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46A70C4167B for ; Sun, 10 Dec 2023 01:00:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231398AbjLJAfI (ORCPT ); Sat, 9 Dec 2023 19:35:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229488AbjLJAfG (ORCPT ); Sat, 9 Dec 2023 19:35:06 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C9BBE7 for ; Sat, 9 Dec 2023 16:35:13 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1704C433C7; Sun, 10 Dec 2023 00:35:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702168512; bh=u+cXPj/slh1aFMEJSuOOp1f8U3gz4OU5Qb61R98fQFY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aO75rSnL2pN+RxPsPFQQcEUYG/FfbjHIWrG72uV21BCtrU5nfycNAOkx7M+DDVUzU e4aNBYcs4b/0/8qplP2newjAx+vT6T8nv2BuBy8zWH+korOcWD6WS0fwdXRxF4H+Xw ahkv/gQqc1nymrWWu6bHl2KOf2QBTbBcGNprM5lnzmxSyxa/R41dDtmVSuvLkrG04B mm6WtQWXBRWAV7lcKtIdXUqOC3j4xrSwqMX1y7ds40OrYZbbNM84OnWIVj/wtD6AY8 iTXHiNVqWiw8EyX9EgUy6D1YVmSofhHULtMZafQiNFwM4abwCtnwkCORRNd6A/X0qo v3ZvwYmjpkW3w== Date: Sun, 10 Dec 2023 01:35:07 +0100 From: Frederic Weisbecker To: Anna-Maria Behnsen Cc: Sebastian Siewior , linux-kernel@vger.kernel.org, Peter Zijlstra , John Stultz , Thomas Gleixner , Eric Dumazet , "Rafael J . Wysocki" , Arjan van de Ven , "Paul E . McKenney" , Rik van Riel , Steven Rostedt , Giovanni Gherdovich , Lukasz Luba , "Gautham R . Shenoy" , Srinivas Pandruvada , K Prateek Nayak Subject: Re: [PATCH v9 12/32] timers: Fix nextevt calculation when no timers are pending Message-ID: References: <20231201092654.34614-1-anna-maria@linutronix.de> <20231201092654.34614-13-anna-maria@linutronix.de> <20231204160350.OTCnqCJf@linutronix.de> <87zfyodfxc.fsf@somnus> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87zfyodfxc.fsf@somnus> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le Tue, Dec 05, 2023 at 12:53:03PM +0100, Anna-Maria Behnsen a écrit : > Sebastian Siewior writes: > >> Use only base->next_expiry value as nextevt when timers are > >> pending. Otherwise nextevt will be jiffies + NEXT_TIMER_MAX_DELTA. As all > >> information is in place, update base->next_expiry value of the empty timer > >> base as well. > > > > or consider timers_pending in run_local_timers()? An additional read vs > > write? > > This would also be a possibility to add the check in run_local_timers() > with timers_pending. We could but do we really care about avoiding a potential softirq every 12 days (on 1000 Hz...) > And we also have to make the is_idle marking in > get_next_timer_interrupt() dependant on base::timers_pending bit. Yes that, on the other hand, looks mandatory! Because if the CPU sleeps for 12 days and then gets an interrupt and then go back to sleep, base->is_idle will be set as false and remote enqueues won't be notified. > But this also means, we cannot rely on next_expiry when no timer is pending. But note that this patch only fixes that partially anyway. Suppose the tick is stopped entirely and the CPU sleeps for 13 days without any interruption. Then it's woken up with TIF_RESCHED without any timer queued, get_next_timer_interrupt() won't be called upon tick restart to fix ->next_expiry. > > Frederic, what do you think? So it looks like is_idle must be fixed. As for the timer softirq, ->next_expiry is already unreliable because when a timer is removed, ->next_expiry is not updated (even though that removed timer might have been the earliest). So ->next_expiry can already carry a "too early" value. The only constraint is that ->next_expiry can't be later than the first timer. So I'd rather put a comment somewhere about the fact that wrapping is expected to behave ok. But it's your call. Thanks.