From: Thomas Gleixner <tglx@linutronix.de>
To: Aaron Tomlin <atomlin@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Christoph Lameter <cl@gentwo.de>,
frederic@kernel.org, mingo@kernel.org, pauld@redhat.com,
neelx@redhat.com, oleksandr@natalenko.name,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
Date: Wed, 27 Apr 2022 16:40:19 +0200 [thread overview]
Message-ID: <875ymuy4h8.ffs@tglx> (raw)
In-Reply-To: <20220427115020.kyaxc5j67lq5zrfq@ava.usersys.com>
On Wed, Apr 27 2022 at 12:50, Aaron Tomlin wrote:
> On Mon 2022-04-25 16:21 -0300, Marcelo Tosatti wrote:
>> Is there anything that prevents a nohz full CPU from running an
>> application with short and frequent idling?
>
> I'm not sure I understand the question; albeit, if I understand correctly,
> yes: the scheduling-clock tick, if it was stopped.
> Yet I believe this behaviour is correct. Consider the following example:
>
> When a CFS task is moved/or migrated to a nohz_full CPU that was
> previously idle and had its tick stopped, if its the only task on the
> run-queue then it is possible that the idle task may not restart the
> tick (see __tick_nohz_full_update_tick()). Thus once the CFS task exits
> manual intervention i.e. a reschedule IPI to wake the idle task, would be
> required to run again, on the same CPU.
When the task exits and the tick was stopped, why should idle restart
the tick? There is nothing to do, so what?
Thanks,
tglx
next prev parent reply other threads:[~2022-04-27 14:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 19:36 Aaron Tomlin
2022-04-25 7:23 ` Christoph Lameter
2022-04-25 11:39 ` Aaron Tomlin
2022-04-25 12:09 ` Christoph Lameter
2022-04-25 13:27 ` Peter Zijlstra
2022-04-25 14:06 ` Christoph Lameter
2022-04-25 14:51 ` Aaron Tomlin
2022-04-25 14:57 ` Marcelo Tosatti
2022-04-25 14:17 ` Aaron Tomlin
2022-04-25 19:21 ` Marcelo Tosatti
2022-04-27 11:50 ` Aaron Tomlin
2022-04-27 14:40 ` Thomas Gleixner [this message]
2022-04-27 14:49 ` Aaron Tomlin
2022-04-28 18:10 ` Marcelo Tosatti
2022-05-04 9:32 ` Aaron Tomlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875ymuy4h8.ffs@tglx \
--to=tglx@linutronix.de \
--cc=atomlin@redhat.com \
--cc=cl@gentwo.de \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@kernel.org \
--cc=mtosatti@redhat.com \
--cc=neelx@redhat.com \
--cc=oleksandr@natalenko.name \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox