From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 120AA19F11B for ; Tue, 28 Jan 2025 14:44:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738075494; cv=none; b=t+Tjm3cxxW/4jba1gdnOetiAbusuSxtJrUsXLTSzIroWJ00IHds4i3afiX4bJuPRqPcaQJTv60pfOcRVSuXGCswYoQoi5/etrE+PLI+Rqicni8ewlQCcPRkVCZWYUkAlVXL2uid5Kt53DHCaLUjo/EYTebZZLEnUaR45w0ERqdE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738075494; c=relaxed/simple; bh=4g7ZF/ZeIcGnBex2OW/KiV2tcbxv4FEJKidnDX7RxJ0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=LHv4dpN+rKDwhCdYZiFlTg6HtTV+RxZ/+WHDjzrqzDapfy8BjTNELGkMyPYaIhlmpet/iG/c4vVJBACKCduaZOe9HQP7FhHZWzXa0TRn5VuMZbu3AwqJrM03sJn7y1qbtv+4N9wkm8See+IKpFMCWZo1EAD3uJ3w8WYTf7ylnOo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=vjni4QZj; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=mzxMpuvR; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="vjni4QZj"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="mzxMpuvR" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738075484; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kwHCrLUQbgPd7QVWz33kCrObwKSjSqzHay+0Bgi96/k=; b=vjni4QZjKM+OVc4LlJUBSXNcP84ywm7pak7d1WfJv8VN/fi6ZGSZ7WhmXjQC/GsdCQnIWR 40MxhJ3KTbd8zR6qV2dXNqb3AEl3+bTiNTE2jgjFp29NXrEFsbM+lCSLLmNK3OGfa5pIM+ 6NDg+RXTMXE+wdPWTIe7a70LpvYm6OYy3dHqV1eiR416vFB7ys02LYVC6xVlBfFkf3MeS3 JVqV5xLP5r24UBc+cLz8J7avljO+ZoQAx9B3We4efn++GtLC/Nnrc+IUXX5Fhv54Y4fz6G fC/nd4IJGAFjHcwmCYbL3lDUzy93DUY5iNWvv6tTZa4n1ph9rvxHkXTbN1YkTA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738075484; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kwHCrLUQbgPd7QVWz33kCrObwKSjSqzHay+0Bgi96/k=; b=mzxMpuvRy1OKI1BRuOCflrMn/fb1YlqH6nN61ukl4DPfrX9L4oHXr7yY3I6JIjCxyNJqI6 uRMJolFxRY0uOXAA== To: John Stultz , LKML Cc: John Stultz , Anna-Maria Behnsen , Frederic Weisbecker , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Stephen Boyd , Yury Norov , Bitao Hu , Andrew Morton , kernel-team@android.com Subject: Re: [RFC][PATCH 1/3] time/tick: Pipe tick count down through cputime accounting In-Reply-To: <20250128063301.3879317-2-jstultz@google.com> References: <20250128063301.3879317-1-jstultz@google.com> <20250128063301.3879317-2-jstultz@google.com> Date: Tue, 28 Jan 2025 15:44:43 +0100 Message-ID: <877c6f80bo.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Jan 27 2025 at 22:32, John Stultz wrote: > In working up the dynHZ patch, I found that the skipping of > ticks would result in large latencies for itimers. > > As I dug into it, I realized there is still some logic that > assumes we don't miss ticks, resulting in late expiration of > cputime timers. > > So this patch pipes the actual number of ticks passed down > through cputime accounting. This word salad does not qualify as a proper technical changelog. See Documentation/ > /* > * Must be called with interrupts disabled ! > */ > -static void tick_do_update_jiffies64(ktime_t now) > +static unsigned long tick_do_update_jiffies64(ktime_t now) > { > unsigned long ticks = 1; > ktime_t delta, nextp; > @@ -70,7 +70,7 @@ static void tick_do_update_jiffies64(ktime_t now) > */ > if (IS_ENABLED(CONFIG_64BIT)) { > if (ktime_before(now, smp_load_acquire(&tick_next_period))) > - return; > + return 0; So if the CPU's tick handler does not update jiffies, then this returns zero ticks.... > -static void tick_sched_do_timer(struct tick_sched *ts, ktime_t now) > +static unsigned long tick_sched_do_timer(struct tick_sched *ts, ktime_t now) > { > int tick_cpu, cpu = smp_processor_id(); > - > + unsigned long ticks = 0; And you have also zero ticks, when the CPU is not the tick_cpu: > /* Check if jiffies need an update */ > if (tick_cpu == cpu) > - tick_do_update_jiffies64(now); > + ticks = tick_do_update_jiffies64(now); ... > + return ticks; > } > > -static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs) > +static void tick_sched_handle(struct tick_sched *ts, unsigned long ticks, struct pt_regs *regs) > { > /* > * When we are idle and the tick is stopped, we have to touch > @@ -264,7 +266,7 @@ static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs) > tick_sched_flag_test(ts, TS_FLAG_STOPPED)) { > touch_softlockup_watchdog_sched(); > if (is_idle_task(current)) > - ts->idle_jiffies++; > + ts->idle_jiffies += ticks; > /* > * In case the current tick fired too early past its expected > * expiration, make sure we don't bypass the next clock reprogramming > @@ -273,7 +275,7 @@ static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs) > ts->next_tick = 0; > } > > - update_process_times(user_mode(regs)); > + update_process_times(ticks, user_mode(regs)); Which is then fed to update_process_times() and subsequently to account_process_ticks(). IOW, any CPUs tick handler which does not actually advance jiffies is going to account ZERO ticks... Seriously? Thanks, tglx