From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 4061A314A84 for ; Mon, 4 May 2026 08:04:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777881881; cv=none; b=ojIXkpxUWy/VwrXqmYzmf9/lZNo8OikNZUKrfIfOe/7ZG2Sx4zIeumPPYa3cA/5SHSg73ZDUIO1aMvHOoxCAi4neB2FtJMUL0LZbXynVeIl2dEpe5GyaaLqsRS/9erur17x9Wlc1APLYvvcmxhtAJNDgCQrfgtpqYY1wUFP41U0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777881881; c=relaxed/simple; bh=1D8quZ8Qp0K6TT7lFBXae7NIk9KB9gs6o8IFaY1njT8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ez8n8PxSo8ug0FhcWuq1+Wer+cwApganFERe9BCGatF+6I4oxqCPRJomR5t1a4kCunm3dEbTa4yT1AS2w0MM/sBYiHX3SRzglEes1hiPhWKVUlrIq24xiTI1MnKg/8iuv/CzdI7COTH0zuoldeNtfsidp4e+j7sRt0ssaQGle4w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ETRrXLgh; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ETRrXLgh" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=dm9nQNsukWqjys9oX+BbMSvGeBfpTg15NaQkZeND+oU=; b=ETRrXLghwkBAo2x9mSSj0RrMIr MgiP2TCHP49yLjlFPMioFMP2U7M2X1i7aWvlGlw9ksXkyLJdNuKwCcs9lTfJ013LwclXYVFn3aiPb KkB9X1c/sEfscJdX6MiAnZVL75dvM4GPYpDFzeX9LQgcLeG/UYGdTI5Z372uuQC82Z3TgCEy/Iz7r UBg8Esa7V2PoZsDSsnC2DQ37yIFxB58jBA9evoAcn8gW84MLGv/IePJcCRE/GAvAH3428i0dA4ud8 Kg3qhXB7BQaXehW68x0Dqy5bnkl1ZEp/0AUF2ktuMfWTtW1bNfPjI8Jg4H5h3TeBfbiJP2REoBjKo i7YUXDaQ==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1wJoI7-00000000YVH-3d9N; Mon, 04 May 2026 08:04:35 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 7BE1C300390; Mon, 04 May 2026 10:04:34 +0200 (CEST) Date: Mon, 4 May 2026 10:04:34 +0200 From: Peter Zijlstra To: Zhan Xusheng Cc: Johannes Weiner , Ingo Molnar , linux-kernel@vger.kernel.org, Zhan Xusheng Subject: Re: [PATCH v4] sched/psi: Skip CPUs with zero non-idle delta in per-CPU aggregation Message-ID: <20260504080434.GN3126523@noisy.programming.kicks-ass.net> References: <20260429100555.179348-1-zhanxusheng@xiaomi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260429100555.179348-1-zhanxusheng@xiaomi.com> On Wed, Apr 29, 2026 at 06:05:55PM +0800, Zhan Xusheng wrote: > collect_percpu_times() iterates over every possible CPU to build a > non-idle-weighted average of the PSI state times. When a CPU has > no PSI_NONIDLE delta for the current sampling interval: > nonidle = nsecs_to_jiffies(times[PSI_NONIDLE]) = 0 > deltas[s] += times[s] * nonidle /* += 0 */ > > so the weighted accumulation contributes nothing. > > get_recent_times() already sets the PSI_NONIDLE bit in > cpu_changed_states iff the PSI_NONIDLE delta is non-zero. Use that > bit to skip such CPUs early, as suggested by Johannes, avoiding the > nsecs_to_jiffies() call. > > No functional change intended. So presumably this is an optimization. Where is the data that justifies this?