Message ID | 20231215130501.24542-1-anna-maria@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-971-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp9256769dys; Fri, 15 Dec 2023 05:06:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IHt0r8M05wLy88RhMcr18PU6FS8XUpqLHXTtgmODLIJv1jf2lk1MlZkwBx2Ja2MeD3riGnb X-Received: by 2002:a17:903:704:b0:1d3:3a00:d8de with SMTP id kk4-20020a170903070400b001d33a00d8demr5758518plb.30.1702645577098; Fri, 15 Dec 2023 05:06:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702645577; cv=none; d=google.com; s=arc-20160816; b=YkY/lmW9Z52dqY0le0cDIP5eqZMZQ9rGfL4z/Qz0iWFZLddB+IN15z6Z1zudXOTz4w qqK3AaSibEF0lFu0vJv5fjGe5hGqyt45oERScM/ikcAZRMaTYVH5FXGnX7Hv+GFcMuxH g8cla4sx/yXssTf9T29lM2uD1yLnhJO/o55uzb6D/VznmUhDPEANP1h7qE0+kyq0lBUa DJYOUkyU+EdRy6p6h1XlqLxs8WE44vScPPQ75qUi2bODiqtUXrCAVoVblhfrsNCWVlfB 8zcy98BmBMhLjzpo3zIRMwQXmYJ4v9m7Il6Yb/+JnUVcBT3yZwpsRYGSuOHfCzfyy+pz u7Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :dkim-signature:dkim-signature:from; bh=U2tDiKHKYr5BFBF9MXdN4euPv07ro9CC99NNHl3ihkg=; fh=8eucRM/E/6Vm+s9321T/RQBjZf79bIaNiF/9aTHmHWo=; b=C4mzz0BKeB62rkXcWwfWh78n0QdiUbPDG6G3EucCp10yyGy5xIQW6r3mgETyv0b3dd CLNagIAef+ceVfzkY68nW7DHj99AzWl+U6CitQFOAXS6rY+Xr5nRjnGWuCx/Pjbmg4Wj usB/QoOfXnst5d8uBY9D4ci0B/8SHBonEGc/iJmdKurDEVZuUB4allNkKpd3rEUuaaPW ImgcN+OpdG/0UTG3aMMxtyW44bqLRscCWR2R5zFuzbXaQOj3BJhJ6dks/jkr9YV3kOis RY/FsIkClDM3WtSEmEqyMamT59sDwiDYatu/gA74wpTQhy+dpj/R9UhluXcHzUXwEVBh tZCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=rlNUTVj1; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel+bounces-971-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-971-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id n7-20020a1709026a8700b001d356043820si3981650plk.604.2023.12.15.05.06.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 05:06:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-971-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=rlNUTVj1; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel+bounces-971-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-971-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 8F64BB23703 for <ouuuleilei@gmail.com>; Fri, 15 Dec 2023 13:05:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6658F2DB6D; Fri, 15 Dec 2023 13:05:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="rlNUTVj1"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="aCbWa5Az" X-Original-To: linux-kernel@vger.kernel.org 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 3A4B22DB7C for <linux-kernel@vger.kernel.org>; Fri, 15 Dec 2023 13:05:13 +0000 (UTC) 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 From: Anna-Maria Behnsen <anna-maria@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1702645511; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=U2tDiKHKYr5BFBF9MXdN4euPv07ro9CC99NNHl3ihkg=; b=rlNUTVj11k9F9xc53az5oRZhTvMk3vR94kDWFOfa7PKvXnflbuwCP1YKdtZGHxLpdRhcgg fDm25g5wa4AfJJLPZK2dxPjsW2nBasLq4ivhyW54mNkGHLlGMcy46RAmGtr+8CtBkltUFP a00rKENsxQjPdgL8Wuhu8eWz9LhHREfhMsEashAZZ9/I0vIvFrbEle23ziddTULY32XYKT NURUrmnfZ/rMFgoT3TeGgb/Uoe4G7quDjS6FlR8LZFqtesbqjcADn2ZmTYx43LJZgjByGc MUOIjFrFOXGNCvrdwoTMJpXW9qa+k85M5Ox2A7EhML7EYrK0JtetLNekGnRN6w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1702645511; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=U2tDiKHKYr5BFBF9MXdN4euPv07ro9CC99NNHl3ihkg=; b=aCbWa5AznxUTz9+fLqfPxDsN2XeRkh9QsBGsRJ837u6cYvKn96zQhQAwbLWBVxvV1EGE+i +rFPQBp4IS/u5cCw== To: linux-kernel@vger.kernel.org Cc: Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Daniel Bristot de Oliveira <bristot@redhat.com>, Valentin Schneider <vschneid@redhat.com>, Thomas Gleixner <tglx@linutronix.de> Subject: [PATCH] sched/idle: Prevent stopping the tick when there is no cpuidle driver Date: Fri, 15 Dec 2023 14:05:01 +0100 Message-Id: <20231215130501.24542-1-anna-maria@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785353288488644005 X-GMAIL-MSGID: 1785353288488644005 |
Series |
sched/idle: Prevent stopping the tick when there is no cpuidle driver
|
|
Commit Message
Anna-Maria Behnsen
Dec. 15, 2023, 1:05 p.m. UTC
When there is no cpuidle driver, the system tries to stop the tick even if
the system is fully loaded. But stopping the tick is not for free and it
decreases performance on a fully loaded system. As there is no (cpuidle)
framework which brings CPU in a power saving state when nothing needs to be
done, there is also no power saving benefit when stopping the tick.
Therefore do not stop the tick when there is no cpuidle driver.
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
---
kernel/sched/idle.c | 2 --
1 file changed, 2 deletions(-)
Comments
Hello Anna-Maria, On 12/15/23 14:05, Anna-Maria Behnsen wrote: > When there is no cpuidle driver, the system tries to stop the tick even if > the system is fully loaded. But stopping the tick is not for free and it > decreases performance on a fully loaded system. As there is no (cpuidle) > framework which brings CPU in a power saving state when nothing needs to be > done, there is also no power saving benefit when stopping the tick. Just in case is wasn't taken into consideration: - Stopping the tick isn't free on a busy system, but it should also cost something to regularly handle ticks on each CPU of an idle system. FWIU, disabling the ticks also allows to add a CPU to the 'nohz.idle_cpus_mask' mask, which helps the idle load balancer picking an idle CPU to do load balancing for all the idle CPUs (cf. kick_ilb()). It seems better to do one periodic balancing for all the idle CPUs rather than periodically waking-up all CPUs to try to balance. - I would have assumed that if the system was fully loaded, ticks would not be stopped, or maybe I misunderstood the case. I assume the wake-up latency would be improved if the tick doesn't have to be re-setup again. Regards, Pierre > > Therefore do not stop the tick when there is no cpuidle driver. > > Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> > --- > kernel/sched/idle.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c > index 565f8374ddbb..fd111686aaf3 100644 > --- a/kernel/sched/idle.c > +++ b/kernel/sched/idle.c > @@ -165,8 +165,6 @@ static void cpuidle_idle_call(void) > */ > > if (cpuidle_not_available(drv, dev)) { > - tick_nohz_idle_stop_tick(); > - > default_idle_call(); > goto exit_idle; > }
Hello Pierre, Pierre Gondois <pierre.gondois@arm.com> writes: > Hello Anna-Maria, > > On 12/15/23 14:05, Anna-Maria Behnsen wrote: >> When there is no cpuidle driver, the system tries to stop the tick even if >> the system is fully loaded. But stopping the tick is not for free and it >> decreases performance on a fully loaded system. As there is no (cpuidle) >> framework which brings CPU in a power saving state when nothing needs to be >> done, there is also no power saving benefit when stopping the tick. > > Just in case is wasn't taken into consideration: > - > Stopping the tick isn't free on a busy system, but it should also cost > something to regularly handle ticks on each CPU of an idle system. > > FWIU, disabling the ticks also allows to add a CPU to the 'nohz.idle_cpus_mask' > mask, which helps the idle load balancer picking an idle CPU to do load > balancing for all the idle CPUs (cf. kick_ilb()). > > It seems better to do one periodic balancing for all the idle CPUs rather > than periodically waking-up all CPUs to try to balance. > > - > I would have assumed that if the system was fully loaded, ticks would > not be stopped, or maybe I misunderstood the case. > I assume the wake-up latency would be improved if the tick doesn't > have to be re-setup again. > Your answer confuses me a little... When there is a cpuidle driver, trying to stop the tick is not done unconditionally. It is only done when the CPU is in a state that it could go into a deeper C sleep - this is decided by cpuidle driver/governor. When there is no cpuidle driver, there is no instance which could bring the CPU into a deeper C state. But at the moment the code does unconditionally try to stop the tick. So the aim of the patch is to remove this unconditional stop of the tick. And NOHZ is independant on the cpuidle infrastructure. But when there is no cpuidle driver, it doesn't makes sense to use then also NOHZ. Thanks, Anna-Maria
Hello Anna-Maria, On 1/9/24 17:24, Anna-Maria Behnsen wrote: > Hello Pierre, > > Pierre Gondois <pierre.gondois@arm.com> writes: > >> Hello Anna-Maria, >> >> On 12/15/23 14:05, Anna-Maria Behnsen wrote: >>> When there is no cpuidle driver, the system tries to stop the tick even if >>> the system is fully loaded. But stopping the tick is not for free and it >>> decreases performance on a fully loaded system. As there is no (cpuidle) >>> framework which brings CPU in a power saving state when nothing needs to be >>> done, there is also no power saving benefit when stopping the tick. >> >> Just in case is wasn't taken into consideration: >> - >> Stopping the tick isn't free on a busy system, but it should also cost >> something to regularly handle ticks on each CPU of an idle system. >> >> FWIU, disabling the ticks also allows to add a CPU to the 'nohz.idle_cpus_mask' >> mask, which helps the idle load balancer picking an idle CPU to do load >> balancing for all the idle CPUs (cf. kick_ilb()). >> >> It seems better to do one periodic balancing for all the idle CPUs rather >> than periodically waking-up all CPUs to try to balance. >> >> - >> I would have assumed that if the system was fully loaded, ticks would >> not be stopped, or maybe I misunderstood the case. >> I assume the wake-up latency would be improved if the tick doesn't >> have to be re-setup again. >> > > Your answer confuses me a little... > > When there is a cpuidle driver, trying to stop the tick is not done > unconditionally. It is only done when the CPU is in a state that it > could go into a deeper C sleep - this is decided by cpuidle > driver/governor. Yes right. > > When there is no cpuidle driver, there is no instance which could bring > the CPU into a deeper C state. But at the moment the code does > unconditionally try to stop the tick. So the aim of the patch is to > remove this unconditional stop of the tick. I agree that the absence of cpuidle driver prevents from reaching deep idle states. FWIU, there is however still benefits in stopping the tick on such platform. - I agree that bringing up/down the ticks costs something and that removing tick_nohz_idle_stop_tick() can improve performance, but I assumed stopping the ticks had some interest regarding energy consumption. Keeping the tick forever on an idle CPU should not be useful. - About nohz.idle_cpus_mask, I was referring to the following path: do_idle() \-cpuidle_idle_call() \-tick_nohz_idle_stop_tick() \-nohz_balance_enter_idle() \-cpumask_set_cpu(cpu, nohz.idle_cpus_mask); \-atomic_inc(&nohz.nr_cpus); Removing tick_nohz_idle_stop_tick() also means not using nohz.idle_cpus_mask and the logic around it to find an idle CPU to balance tasks. Hope the re-phrasing makes the 2 points a bit clearer, Regards, Pierre > > And NOHZ is independant on the cpuidle infrastructure. But when there is > no cpuidle driver, it doesn't makes sense to use then also NOHZ. > > Thanks, > > Anna-Maria > > >
Pierre Gondois <pierre.gondois@arm.com> writes: > Hello Anna-Maria, > > On 1/9/24 17:24, Anna-Maria Behnsen wrote: >> >> When there is no cpuidle driver, there is no instance which could bring >> the CPU into a deeper C state. But at the moment the code does >> unconditionally try to stop the tick. So the aim of the patch is to >> remove this unconditional stop of the tick. > > I agree that the absence of cpuidle driver prevents from reaching deep > idle states. FWIU, there is however still benefits in stopping the tick > on such platform. What's the benefit? Thanks, Anna-Maria
Hello Anna-Maria, On 1/12/24 11:56, Anna-Maria Behnsen wrote: > Pierre Gondois <pierre.gondois@arm.com> writes: > >> Hello Anna-Maria, >> >> On 1/9/24 17:24, Anna-Maria Behnsen wrote: >>> >>> When there is no cpuidle driver, there is no instance which could bring >>> the CPU into a deeper C state. But at the moment the code does >>> unconditionally try to stop the tick. So the aim of the patch is to >>> remove this unconditional stop of the tick. >> >> I agree that the absence of cpuidle driver prevents from reaching deep >> idle states. FWIU, there is however still benefits in stopping the tick >> on such platform. > > What's the benefit? I did the following test: - on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs) - booting with 'cpuidle.off=1' - using the energy counters of the platforms (the counters measure energy for the whole cluster of big/little CPUs) - letting the platform idling during 10s Without patch: | | big-CPUs | little-CPUs | |:------|-------------:|------------:| | count | 10 | 10 | | mean | 0.353266 | 0.33399 | | std | 0.000254574 | 0.00206803 | | min | 0.352991 | 0.332145 | | 25% | 0.353039 | 0.332506 | | 50% | 0.353267 | 0.333089 | | 75% | 0.353412 | 0.335231 | | max | 0.353737 | 0.337964 | With patch: | | big-CPUs | little-CPUs | |:------|-------------:|-------------:| | count | 10 | 10 | | mean | 0.375086 | 0.352451 | | std | 0.000299919 | 0.000752727 | | min | 0.374527 | 0.351743 | | 25% | 0.374872 | 0.35181 | | 50% | 0.37512 | 0.352063 | | 75% | 0.375335 | 0.353256 | | max | 0.375485 | 0.353461 | So the energy consumption would be up: - ~6% for the big CPUs - ~10% for the litte CPUs Regards, Pierre > > Thanks, > > Anna-Maria >
On Fri, Jan 12 2024 at 14:39, Pierre Gondois wrote: > On 1/12/24 11:56, Anna-Maria Behnsen wrote: >> Pierre Gondois <pierre.gondois@arm.com> writes: >>> I agree that the absence of cpuidle driver prevents from reaching deep >>> idle states. FWIU, there is however still benefits in stopping the tick >>> on such platform. >> >> What's the benefit? > > I did the following test: > - on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs) > - booting with 'cpuidle.off=1' > - using the energy counters of the platforms > (the counters measure energy for the whole cluster of big/little CPUs) > - letting the platform idling during 10s > > So the energy consumption would be up: > - ~6% for the big CPUs > - ~10% for the litte CPUs Fair enough, but what's the actual usecase? NOHZ w/o cpuidle driver seems a rather academic exercise to me. Thanks, tglx
Hello Thomas, On 1/12/24 15:52, Thomas Gleixner wrote: > On Fri, Jan 12 2024 at 14:39, Pierre Gondois wrote: >> On 1/12/24 11:56, Anna-Maria Behnsen wrote: >>> Pierre Gondois <pierre.gondois@arm.com> writes: >>>> I agree that the absence of cpuidle driver prevents from reaching deep >>>> idle states. FWIU, there is however still benefits in stopping the tick >>>> on such platform. >>> >>> What's the benefit? >> >> I did the following test: >> - on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs) >> - booting with 'cpuidle.off=1' >> - using the energy counters of the platforms >> (the counters measure energy for the whole cluster of big/little CPUs) >> - letting the platform idling during 10s >> >> So the energy consumption would be up: >> - ~6% for the big CPUs >> - ~10% for the litte CPUs > > Fair enough, but what's the actual usecase? > > NOHZ w/o cpuidle driver seems a rather academic exercise to me. I thought Anna-Maria had a use-case for this. I just wanted to point out that this patch could potentially increase the energy consumption for her use-case, nothing more, Regards, Pierre > > Thanks, > > tglx
Pierre Gondois <pierre.gondois@arm.com> writes: > Hello Thomas, > > On 1/12/24 15:52, Thomas Gleixner wrote: >> On Fri, Jan 12 2024 at 14:39, Pierre Gondois wrote: >>> On 1/12/24 11:56, Anna-Maria Behnsen wrote: >>>> Pierre Gondois <pierre.gondois@arm.com> writes: >>>>> I agree that the absence of cpuidle driver prevents from reaching deep >>>>> idle states. FWIU, there is however still benefits in stopping the tick >>>>> on such platform. >>>> >>>> What's the benefit? >>> >>> I did the following test: >>> - on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs) >>> - booting with 'cpuidle.off=1' >>> - using the energy counters of the platforms >>> (the counters measure energy for the whole cluster of big/little CPUs) >>> - letting the platform idling during 10s >>> >>> So the energy consumption would be up: >>> - ~6% for the big CPUs >>> - ~10% for the litte CPUs >> >> Fair enough, but what's the actual usecase? >> >> NOHZ w/o cpuidle driver seems a rather academic exercise to me. > > I thought Anna-Maria had a use-case for this. > I just wanted to point out that this patch could potentially > increase the energy consumption for her use-case, nothing more, > I saw tons of calls trying to stop the tick on a loaded system - which decreased performance. Deep sleep states were disabled (by accident) in the BIOS but NOHZ was enabled. So my proposal is to remove this unconditional call trying to stop the tick. Thanks, Anna-Maria
On Mon, 15 Jan 2024 at 13:40, Pierre Gondois <pierre.gondois@arm.com> wrote: > > Hello Thomas, > > On 1/12/24 15:52, Thomas Gleixner wrote: > > On Fri, Jan 12 2024 at 14:39, Pierre Gondois wrote: > >> On 1/12/24 11:56, Anna-Maria Behnsen wrote: > >>> Pierre Gondois <pierre.gondois@arm.com> writes: > >>>> I agree that the absence of cpuidle driver prevents from reaching deep > >>>> idle states. FWIU, there is however still benefits in stopping the tick > >>>> on such platform. > >>> > >>> What's the benefit? > >> > >> I did the following test: > >> - on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs) > >> - booting with 'cpuidle.off=1' > >> - using the energy counters of the platforms > >> (the counters measure energy for the whole cluster of big/little CPUs) > >> - letting the platform idling during 10s > >> > >> So the energy consumption would be up: > >> - ~6% for the big CPUs > >> - ~10% for the litte CPUs > > > > Fair enough, but what's the actual usecase? > > > > NOHZ w/o cpuidle driver seems a rather academic exercise to me. Don't know if it's really a valid use case but can't we have VMs in such a configuration ? NOHZ enabled and no cpuidle driver as VM doesn't manage HW anyway ? > > I thought Anna-Maria had a use-case for this. > I just wanted to point out that this patch could potentially > increase the energy consumption for her use-case, nothing more, > > Regards, > Pierre > > > > > Thanks, > > > > tglx
On 1/15/24 14:29, Vincent Guittot wrote: > On Mon, 15 Jan 2024 at 13:40, Pierre Gondois <pierre.gondois@arm.com> wrote: >> >> Hello Thomas, >> >> On 1/12/24 15:52, Thomas Gleixner wrote: >>> On Fri, Jan 12 2024 at 14:39, Pierre Gondois wrote: >>>> On 1/12/24 11:56, Anna-Maria Behnsen wrote: >>>>> Pierre Gondois <pierre.gondois@arm.com> writes: >>>>>> I agree that the absence of cpuidle driver prevents from reaching deep >>>>>> idle states. FWIU, there is however still benefits in stopping the tick >>>>>> on such platform. >>>>> >>>>> What's the benefit? >>>> >>>> I did the following test: >>>> - on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs) >>>> - booting with 'cpuidle.off=1' >>>> - using the energy counters of the platforms >>>> (the counters measure energy for the whole cluster of big/little CPUs) >>>> - letting the platform idling during 10s >>>> >>>> So the energy consumption would be up: >>>> - ~6% for the big CPUs >>>> - ~10% for the litte CPUs >>> >>> Fair enough, but what's the actual usecase? >>> >>> NOHZ w/o cpuidle driver seems a rather academic exercise to me. > > Don't know if it's really a valid use case but can't we have VMs in > such a configuration ? > NOHZ enabled and no cpuidle driver as VM doesn't manage HW anyway ? Yes right, I tried with a kvmtool generated VM and it seemed to be the case: $ grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/available_governors:menu /sys/devices/system/cpu/cpuidle/current_driver:none /sys/devices/system/cpu/cpuidle/current_governor:menu /sys/devices/system/cpu/cpuidle/current_governor_ro:menu > >> >> I thought Anna-Maria had a use-case for this. >> I just wanted to point out that this patch could potentially >> increase the energy consumption for her use-case, nothing more, >> >> Regards, >> Pierre >> >>> >>> Thanks, >>> >>> tglx
Hi, Pierre Gondois <pierre.gondois@arm.com> writes: > On 1/15/24 14:29, Vincent Guittot wrote: >> On Mon, 15 Jan 2024 at 13:40, Pierre Gondois <pierre.gondois@arm.com> wrote: >>> >>> Hello Thomas, >>> >>> On 1/12/24 15:52, Thomas Gleixner wrote: >>>> On Fri, Jan 12 2024 at 14:39, Pierre Gondois wrote: >>>>> On 1/12/24 11:56, Anna-Maria Behnsen wrote: >>>>>> Pierre Gondois <pierre.gondois@arm.com> writes: >>>>>>> I agree that the absence of cpuidle driver prevents from reaching deep >>>>>>> idle states. FWIU, there is however still benefits in stopping the tick >>>>>>> on such platform. >>>>>> >>>>>> What's the benefit? >>>>> >>>>> I did the following test: >>>>> - on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs) >>>>> - booting with 'cpuidle.off=1' >>>>> - using the energy counters of the platforms >>>>> (the counters measure energy for the whole cluster of big/little CPUs) >>>>> - letting the platform idling during 10s >>>>> >>>>> So the energy consumption would be up: >>>>> - ~6% for the big CPUs >>>>> - ~10% for the litte CPUs >>>> >>>> Fair enough, but what's the actual usecase? >>>> >>>> NOHZ w/o cpuidle driver seems a rather academic exercise to me. >> >> Don't know if it's really a valid use case but can't we have VMs in >> such a configuration ? >> NOHZ enabled and no cpuidle driver as VM doesn't manage HW anyway ? > > Yes right, > I tried with a kvmtool generated VM and it seemed to be the case: > > $ grep . /sys/devices/system/cpu/cpuidle/* > /sys/devices/system/cpu/cpuidle/available_governors:menu > /sys/devices/system/cpu/cpuidle/current_driver:none > /sys/devices/system/cpu/cpuidle/current_governor:menu > /sys/devices/system/cpu/cpuidle/current_governor_ro:menu > So it's not on me to decide whether it is valid to skip stopping the tick in this setting or not. I observed this unconditional call (which is not for free) on a fully loaded system which decreases performance. If there is a reasonable condition that could be added for stopping the tick, this might also be a good solution or even a better solution. But only checking whether cpuidle driver is available or not and then unconditionally stopping the tick, doesn't make sense IMHO. Thanks, Anna-Maria
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index 565f8374ddbb..fd111686aaf3 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -165,8 +165,6 @@ static void cpuidle_idle_call(void) */ if (cpuidle_not_available(drv, dev)) { - tick_nohz_idle_stop_tick(); - default_idle_call(); goto exit_idle; }