Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4645087ioa; Wed, 27 Apr 2022 08:08:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8c511duqXwv4opIiL3LTx7yPBxT8n37wWsXu5qQxo5I13CfctfzdUlDDFZf+Uz6LgIZGA X-Received: by 2002:a9d:644b:0:b0:5cd:a627:c439 with SMTP id m11-20020a9d644b000000b005cda627c439mr10123249otl.112.1651072116965; Wed, 27 Apr 2022 08:08:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651072116; cv=none; d=google.com; s=arc-20160816; b=Zc9IigThznvMTvfwCTkcIhP9OCEXdKLmexbpHrB4cmWj2tQ3f0WJOL7NE5iSQE+30Z wjMEkZqW6kzPtmiJ5rdUYmFoclBG0TWbmHCp0Y109sKqgQnoRHrB4remHlsqsCbkzh2T fKeUVQamWrhO2r5LIF1E/BQbH4C1J0pTlEwpqqA2IPDWeI9vs4NgiQ727VJvPUaxx9Dc U6mZ804Cx8tTWIFjiLdEfe197cz7nFVQz7YF4CQEeo+8+LrXwHOtjMMW/cYg1dwE7f26 aTs8qQ/mszE1sr3JCG3Ucmrk1JwAd/754CwV2thOdZUAZwY6+Akfp83mcCl9ZC8xotKT qBew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=3Bh8KuA/AAWOlDEUP/mUP1gM/q09Kmr3g1RCvu7cQIA=; b=NShHmjTGXR4zFEF/fOpBq5ZqOB9KryIwjB4zO1BzgX+A+6G604tfAff3Tq02HAVPB5 2z7lhbr4wvhyCYWUYosHaFWGcMKBnwuzWlSll6dwLyUPyFlDG2KwnUB+DiCR62w4rANl KMdjnNFGAxxqZKjYBOocxvJl2+Q5klts1tYS2Z1or0MsBUMruRZihPpV8VHamk5OKheS ZDC/8FMwzDe/4lKk+igQC3RHpVou9wEMy/Udc/EMEpLcb4H3DLqtK8H7wWNO9ZUepXQS AzHIw0CpzS7zr3dHWQw+MQdi6IBovB9jQy3AIvktjXStUOYca3aBu7XWaNP6dLaWUYHC AzZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=F2bDEcJw; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=OjMdNYOW; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id d17-20020a4aa591000000b0035ea600ec05si182851oom.56.2022.04.27.08.08.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 08:08:36 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=F2bDEcJw; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=OjMdNYOW; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 241ED33EB5; Wed, 27 Apr 2022 07:40:29 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238344AbiD0One (ORCPT + 99 others); Wed, 27 Apr 2022 10:43:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238330AbiD0Ond (ORCPT ); Wed, 27 Apr 2022 10:43:33 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9FE533E8F for ; Wed, 27 Apr 2022 07:40:21 -0700 (PDT) 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-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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