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 D26C7C83F03 for ; Thu, 3 Jul 2025 14:51:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49AFD280002; Thu, 3 Jul 2025 10:51:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4732D940007; Thu, 3 Jul 2025 10:51:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B06E280002; Thu, 3 Jul 2025 10:51:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2B43F940007 for ; Thu, 3 Jul 2025 10:51:06 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C8F7D160229 for ; Thu, 3 Jul 2025 14:51:05 +0000 (UTC) X-FDA: 83623240890.01.D9339A9 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf25.hostedemail.com (Postfix) with ESMTP id 1479EA000D for ; Thu, 3 Jul 2025 14:51:03 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=ARII5J7R; spf=pass (imf25.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751554264; 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=sVN7tqxclINby5tFsFy8G63BdCpieWmpOt0TPox61dA=; b=h9z510G/Gw8+0RQfcGlRFKZ7q7arhSszqu2VolSXsdHt1pcSxZMUUuIw+FRyEBZ7MoBAOj P7XlS2ePBdBvTG4Cxoce0rRp474F7s0gyBwNkjo90+nd3cHXCVvMff7g6zJwe4SW5E1BFp 9Rpvk7E9qsgyL73DbFrXNdFrJ0/KbUM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=ARII5J7R; spf=pass (imf25.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751554264; a=rsa-sha256; cv=none; b=BQgcO0HO2ZKVCUrzeu+YxogCcYeQeIoivswNrNRhDVipU7323C5Uww09s/0JNFbscFJJQN yGIeS1DCwOEI+zAzggrMqBMtjQb+uNYbkW+CrUIxgdwsF4uzP7B9w+hKW+Y3pnCTKyaj9C LDPJC0cOXSmV6pmRgdR1WYl+0oJbYmw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1751554262; bh=ungV5mqcl2Vy/iMA+d0vGPS8BMXuCHpRTM0Lj3frlVw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ARII5J7RARR77OUKyZx/cYaFk5r8rItHWIj95vdjX2POX1SCy+ZIchA3/K+FScSXh iIoMYJFx4xkZd+Rc22ZoYL2vEAIlOeF+yv5gfZQyNQiqJD5LGTURZCUAOLir41eaP4 TIm7nCUiZkeTEV3AzdZ19BzBl1E++KdohU6j+5fU= Received: by gentwo.org (Postfix, from userid 1003) id BD825401F6; Thu, 3 Jul 2025 07:51:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id BC33C401C4; Thu, 3 Jul 2025 07:51:02 -0700 (PDT) Date: Thu, 3 Jul 2025 07:51:02 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Thomas Gleixner 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: <87ms9lwscq.ffs@tglx> Message-ID: <96b6702a-8e3d-0ff9-2a86-75120bac189e@gentwo.org> References: <87sejew87r.ffs@tglx> <87ms9lwscq.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1479EA000D X-Stat-Signature: 77c3u6gqqi6zwhttw74ekg5qq8exeotp X-HE-Tag: 1751554263-367773 X-HE-Meta: U2FsdGVkX1/I1V06gGDdsrEiIgd85/KqkqyNnRbhQlOPLSUDmBz4jACRsRFyc7t3Y4+yBUmK4NSDLCE73GFg96Z8ji/KLwu+GWNX6P6lyG5dKElGylKWKEBRDCVCdxi1ZJ/nzEaI8QTeYJNA6UY6hzfps/Kkm99k/UXZonjGiqyPoAqsUGsCmN2f1Rd9aeS6lNA3rSVkq5Urcfm2XCTQtEPMIRF44jJFQDIJzCalcNU99+TCWaN47joRDUIEURJ+CFLnjvIdzZhl9nfh4/Op0ozXSxavoSOqhBSRr2B66fB2H8tqMDa8WUtxrqq91iEZubGeMY0OIloaJ4fdZZNbbQp0saOp6VHIl2+PLxhYIxl3ERYUBIo6Hhoi1+Ov7G73GlRU6yP1GxZrM6kOb+JMeWM2ao6OioPUxHu5fA8GtoSGSgP0sof0FDh5JVXPIrM9VzeiICmBHur9qMDiJHzpWVnK579iHyQJFwAWZ3FzD01nUd1kH3XUyJEDyXjK+OfX+bTvtJI31q5sF6uZ5hqceQazl7s42yGE3U7gWBQLnjHT18mEu6he6vNELSlg2tZvwVBYSD25Df7bGPv/Tq9JA1CysqcfH/gVqnrGcxXEaX2UY5/wFnAvGIQJNsrbU8VVNaBvtTfqRv563jU5pM8n93Y++T1FmFCVeTKJD/zz5omqqgGrowUqnhw+7vYLl1yTjacOKoEVl/PRHQnPEzybtDH+Vv6IhXMdS27V5ew7U1F81VVp6jxAMs3BNVgW8T4LgEgrMlMUb3CqTt5mUrxj+T14uJlH4Pyu5Hh+CZI3iR8XOlSjUZJqJxlFxfFOtQe59gAay2LxE5LBQDdkvy5MKTlzzCjXTjjcbVx6SIqVljV3FUrJUEzknvs8ARewFaGqC9/hDon8VC9IvFAnlWoxNDvkCZ225mm0fD31O7vtks9JKy/Stpq01narCIM/xYCUvd2pCOXRHPLDJONX5tM syP6AMAA +eB+jheNapHIWH5Re6MDSu4uUC+49iPF2Hccr5XkT0LXkV+dLP+OdRuKXNPwpZ8++bV2LcQVchPJ6xfjLNop8n853NipFUxohwiy6rgliC6qPXUoh1rodZDKt2EDFWSItg0LQLrVDUKHupBbcztvrnJ/vswNEyLrDMatqbP5Jj3Ka1zaVRwAZpKwrSpsd+DLLkl5k2okeiapx0SmiDMaM0Lqc4rIRDP3RSeQFNUbkwbMjBc5wuMwL+2b0ja13QOn3fBFCYfThRte57ta2eVr5iNFGA8Qs4q+iNQj3NcU4iN+elwM= 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, 3 Jul 2025, Thomas Gleixner wrote: > >> So while you preserved the behaviour of the command line option in the > >> most obscure way, you did not even make an attempt to explain why this > >> change does not bring back the issues which caused the removal in commit > >> af5ab277ded0 or why they are irrelevant today. > > > > As pointed out in the patch description: The synchronized tick (aside from > > the jitter) also causes power spikes on large core systems which can cause > > system instabilities. > > That's a _NEW_ problem and has nothing to do with the power saving > concerns which led to af5ab277ded0. The contemporary "advanced on chip power savings" really bite in this scenario. ;-) It was rather suprising to see what can happen. > 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 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. So maybe one idea would be to have a counter of active ticks and skew them if that number gets too high. > - Battery operated devices These usually have 1-4 cores. So synchronized is obviously the best. > - Virtualization (guests) I think there is work to do here to sync the ticks between host and guest for further power savings. > That might not cover 100% of the use cases, but should be a good enough > coverage to base an informed decision on. Yea lets see what others say on the matter. > 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.