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 27171C433EF for ; Wed, 27 Apr 2022 14:40:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A20A56B0073; Wed, 27 Apr 2022 10:40:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A93D6B0075; Wed, 27 Apr 2022 10:40:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 849926B0078; Wed, 27 Apr 2022 10:40:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 75DE56B0073 for ; Wed, 27 Apr 2022 10:40:23 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 418121343 for ; Wed, 27 Apr 2022 14:40:23 +0000 (UTC) X-FDA: 79402919526.11.549DDDC Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf15.hostedemail.com (Postfix) with ESMTP id 530BAA0054 for ; Wed, 27 Apr 2022 14:40:17 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1651070420; 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=3Bh8KuA/AAWOlDEUP/mUP1gM/q09Kmr3g1RCvu7cQIA=; b=F2bDEcJwCXciAlGCONIdOp8h76Zke4rhFmOCALvDr61Pje9+iX+kSae0g/0KZZEyWE4Lhw uu2YbfZ736RWAxpDMHT4rDXjhoymF68y70ALtVFpXDnDIj8LcQvHyIsjuVV6DFBV2D7Nd/ 9SZoe7dRZUVqo00THOHkboeJ/l0GDegoXpsIyxoJBo7EuGxyUngHXeVQSIn0XJCdyJb4n5 w+e2896jnBEf5Q3xE6sPCQM8c8iIDH35AQqZ3MhBmG9kNecefUnM53Tk4fWZsFYBtVuEGx /ZzrKuznkpH7cPQuu23Nm4RtOLEs33aWA8QMQvn3MAlIiLyxkUA46/kxQWYZYw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1651070420; 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=3Bh8KuA/AAWOlDEUP/mUP1gM/q09Kmr3g1RCvu7cQIA=; b=OjMdNYOWGBflZsRQ25IzRNzYQtvuvcM5Q5QldqV9k/keM+3YEoPJ0ButUG4+nckzt3+Nfx vz4ZqhEaLaHTp7Cw== To: Aaron Tomlin , Marcelo Tosatti Cc: Peter Zijlstra , Christoph Lameter , 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 In-Reply-To: <20220427115020.kyaxc5j67lq5zrfq@ava.usersys.com> References: <20220422193647.3808657-1-atomlin@redhat.com> <20220425113909.u3smtztp66svlw4o@ava.usersys.com> <20220425132700.GK2731@worktop.programming.kicks-ass.net> <20220425141717.vw2jfnn3zp6c5ib2@ava.usersys.com> <20220427115020.kyaxc5j67lq5zrfq@ava.usersys.com> Date: Wed, 27 Apr 2022 16:40:19 +0200 Message-ID: <875ymuy4h8.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: h8qzkmqszk1qo13dofn96aaskkrfbu11 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 530BAA0054 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=F2bDEcJw; dkim=pass header.d=linutronix.de header.s=2020e header.b=OjMdNYOW; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf15.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-HE-Tag: 1651070417-791908 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: 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