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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7A60C83F05 for ; Thu, 3 Jul 2025 20:59:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CF138E0011; Thu, 3 Jul 2025 16:59:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 132548E0009; Thu, 3 Jul 2025 16:59:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 021178E0011; Thu, 3 Jul 2025 16:59:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E02588E0009 for ; Thu, 3 Jul 2025 16:59:45 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6D67DBBBBD for ; Thu, 3 Jul 2025 20:59:45 +0000 (UTC) X-FDA: 83624169930.28.3DDA089 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf16.hostedemail.com (Postfix) with ESMTP id A31AA18000B for ; Thu, 3 Jul 2025 20:59:43 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=gyUwQHXq; dkim=pass header.d=linutronix.de header.s=2020e header.b=xxZgy+uk; spf=pass (imf16.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751576384; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CCRmMU2DqQB/WGYJD/I/B9KAT5c7zyCLdXM1Ty+fbzk=; b=tYTQkGMOTZjleuy6XjHxnIXvCCyyqqUjxD5sxMslzry7qihQpNn8J9Yiq+8bCZXHMtQM8q 1XNB2ikuEdnybnjogp+/P2wp1jgBVTS+cFcNaZpL5I+qpKd7kWC9s04qtOXBMbwLxOz8cl WT3EV/lC57QqQS9/39wg24g7DLtkxw4= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=gyUwQHXq; dkim=pass header.d=linutronix.de header.s=2020e header.b=xxZgy+uk; spf=pass (imf16.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751576384; a=rsa-sha256; cv=none; b=q4Rm1aW+skld/LTir/rlfDjzO4Ueyc3CKa5c8HKd+8UJYd5wAG/HfIRiu7aJlJHfzKyuyc +pvuSIF79EbmxzDrjpuudmSdGNHIT2NYaOK8JsW9gryt27lsToCd8kvTtSQ75U7xNHHCE3 ZcfUI/jEVx+4sXZhALfeNxkCtPfDmKE= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1751576381; 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=CCRmMU2DqQB/WGYJD/I/B9KAT5c7zyCLdXM1Ty+fbzk=; b=gyUwQHXqlKlMgNVo6c+8R6S7PRDZM98IX0JPdLsDat90oIN2tKjeeXzJ6u6Dsd2RFvRMTJ zpuj9dr1lkAnrd9kfwb8vcTsPQ/h8QRwK0iWcM93mRqvhxKjy16nkyhF5D8fM7ti3FawHs y34VT/VU2dNujTNpsRklvcsbJXpK6e53eQQNhRfbVXTND/nxT+4fnCIIlswFbV88NA6pYg orzXyigoFdWKAzpkapqqRab+PNiSzX7VDCsNqeEg3Y4lMLxms2EG6/ZyxY4mJ800mwWTJk qZG/lDqSKoFQWk0OAMkYOrr7PSAWL2VrZoom1RxzIiBJwMnU4fcCS039YTVUVQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1751576381; 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=CCRmMU2DqQB/WGYJD/I/B9KAT5c7zyCLdXM1Ty+fbzk=; b=xxZgy+ukjndFizJvg452/dOHMfF8atJjUT4EB3JdR5DollsgfG6qnDk1aS7vM/C9PQuTd0 2oSsSwXEq/tutrDw== To: "Christoph Lameter (Ampere)" Cc: Christoph Lameter via B4 Relay , Anna-Maria Behnsen , Frederic Weisbecker , Ingo Molnar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, sh@gentwo.org, Darren Hart , Arjan van de Ven Subject: Re: [PATCH] Skew tick for systems with a large number of processors In-Reply-To: <96b6702a-8e3d-0ff9-2a86-75120bac189e@gentwo.org> References: <87sejew87r.ffs@tglx> <87ms9lwscq.ffs@tglx> <96b6702a-8e3d-0ff9-2a86-75120bac189e@gentwo.org> Date: Thu, 03 Jul 2025 22:59:40 +0200 Message-ID: <8734bdt2gz.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: nfzamfgnrzzus6ukhats8t549snkfbjn X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A31AA18000B X-HE-Tag: 1751576383-351643 X-HE-Meta: U2FsdGVkX19axp0BQJoFMqGyPnI98I4GDJM2T2ed8Ikhl9zL0HFZ9VdLrNUIV7qb+9lSd0sxnM8eTLUsM6/gfvwsPTHDTp2CRcy/SuWa2FQBlJ043xIeqat1zdUIAXTocb6axDrV1rjukPhx4KF/+KWeRDGKlCHj0WzQvGtBnf4Y9AZK+mdtFuRmyvlJxNec9cGYYNrtcenSl5B5Jubdp1nG93MeV7SJZbCeNUra1sLa3EBe2vKQburSMERitkcmA/VOB89yqrKMzbYn6h10ot1cHRqkTw1yBil/dxyC+cZHAiOj9Iej8G02DV/MzwcargSm6thoccWyhlPyZDcxe096wutiL0BEAjgm9YqLv24iehdut5l+WJwq4hTAl9yOorUejZCI+pCyZVZWaJ0v62kvGIV3tw03qwEW0KRmoQQki44ZYF+s8wbHj3sUosK65DiQR72BnOTrSOOsM1ver/CT1JyvP4Hzx87hOA+yNRs50lM+oO91tQtTYostKkL14CoX/+vhefa4tqqi0PYO5pjfY4FKNg7WfOfc22axN06MUP/7iYAtA7tGGQqwt7U/pMRrfkY9mUY9Ixf3Cyja5ylA1YQEkyAxgb+RHeE3iWpExRakr10BJw0LszcYzWhJpdoJxLEJ/+qh7zGrw5lR5qkBIEEZ5Y98sCL3pcotJvC6NfEkziOO0NDfjZetOhlo4lp+s0rgVOTF3EHOWXZShlxM90GWcszsu1QAFZ/TRVz9nxEtdmN8iJ+eEHLzPnYNVXGYa6DjEjD1uYPtl5Fk55BskIWan7NItHOHcOYWL5UbJQXobaYGV7L4m4E/XHzI88+RxTwLTQeeygYASg1JiX856ZhIthLqmHaWmJH8tuBLKbavJFnBR2PhmgUc6QStBtIoIzoAOan9JKQYczKHgZjdyltIoAFqu/d86nS6aIvbdFbq4WK/o/0GvXgMAbsu16STTMK7S97Gvp6vmi5 yjOIWVvp YGNLfB+5XK8ByV0Hj5PRpdsoAqh47kV9HjSnUAgIMUE30/autA6Me+YPpcaViWxlDs7/TvraBNWSpDWEduD5jX57CQMY4Uo2ox0ZsUNUVOx4CqNFviGZVB5LeGavgeNyG7n5FmxNuyHd1DK9HH09MC0ZoVrwEamGQf2FoWmr+RROafwB7QABUIYE6l6bxkydDym3tbrT6lSuHFAuVzp5Q7qPwUIVoECFQRDti0rGn/a94OlY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jul 03 2025 at 07:51, Christoph Lameter wrote: > On Thu, 3 Jul 2025, Thomas Gleixner wrote: >> It's not rocket science to validate whether these power saving concerns >> still apply and to reach out to people who have been involved in this >> and ask them to revalidate. I just Cc'ed Arjan for you. > > They definitely apply on an Android phone with fewer cores. There you > would want to reduce the number of wakeups as much as possible to > conserver power so it needs synchronized mode. That's kinda obvious, but with the new timer migration model, which stops to place timers by crystalball logic, this might not longer be true and needs actual data to back up that claim. > That is why my initial thought was to make it dependent on the number of > active processors. > >> There is only a limited range of scenarios, which need to be looked at: >> >> - Big servers and the power saving issues on lightly loaded >> machines > > If it is only a few active cores and the system is basically idle then > it is better to have a synchronized tick but if the system has lots of > active processors then the tick should be skewed. I agree with the latter, but is your 'few active cores' claim backed by actual data taken from a current kernel or based on historical evidence and hearsay? > So maybe one idea would be to have a counter of active ticks and skew > them if that number gets too high. The idea itself is not that horrible. Though we should tap into the existing accounting resources to figure that out instead of adding yet another ill defined global counter to the mess. All the required metrics should be there already. Actually it should be solvable if you look at it just from a per CPU perspective. This assumes that NOHZ_IDLE is active, because if it is not then you can just go and skew unconditionally. If a CPU is busy, then it just arms the tick skewed. If it goes idle, then it looks at the expected idle time, which is what NOHZ does already today. If it decides to stop the tick until the next timer list expires, then it aligns it. Earlier expiring high resolution timers obviously override the initial decision, but that's not much different from what is happening today already. >> - Battery operated devices > > These usually have 1-4 cores. So synchronized is obviously the best. Same question as above. >> If we could have predicted the future and the consequences of ad hoc >> decisions, we wouldn't have had a BKL, which took only 20 years of >> effort to get rid of (except for the well hidden leftovers in tty). > > Oh the BKL was good. Synchronization was much faster after all and less > complex. I am sure a BKL approach on small systems would still improve > performance. Feel free to scale back to 4 cores and enjoy the undefined BKL semantics forever in your own fork of 2.2.final :) Thanks, tglx