Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4325519ioa; Wed, 27 Apr 2022 00:48:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8Rwr2cKHxMJkf/9feKYWaNwicu+k6DP4lkh2nGCTZsGdR/3nB1sYDgpBkKtC043KK+2Q0 X-Received: by 2002:a17:906:c113:b0:6d7:7b53:9cb with SMTP id do19-20020a170906c11300b006d77b5309cbmr25966942ejc.197.1651045717817; Wed, 27 Apr 2022 00:48:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651045717; cv=none; d=google.com; s=arc-20160816; b=Seds/1ppMIUvz4ZWV1vlMdd5Mr+eF8E9KVnxa1WF3RC7ICDPBvFyU+dVnNh9Cz0qUe UB4xvdgMquQQW7B1upMF+Hv2JGXGIZfx4z1JyOmXlMYwbcREfdUYeTAVD8KQ0pBW9jnP fcsWops1EMqk5B3hz8Bo3MtdHwsYhk4YuCNrQGscMbW7fR2Gk1noUA8TsNgww6fUT+Nl p4HlENKiOIgbEYheDw4k1Z33vd+SFbPR9QkFEY6kgwrQaPD42ndk836o1Ek8GlRjOsJ0 oTQIovOejXLoinHCkUGzzRjG3+qlu0L7P4wOnQDd92qsO2lG7uMUD2DcP8bTjBFb97bv F35Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=mqmP98i3xVGOSE8p44wlqw/VP2O+Gc6FyNmdWMrFY9w=; b=oMH6xpJJ7Knn1L3JdwdXKD5udpSXnwxNgd4qC0Do7oh+O6x7pD9hJn7N79H/lVLbIm Htl9PtqVshE6cWUXGlJyfe1yZSqbB/8/yUmhZI9QzZr3A6op4VCXQAeiTSSFc31lbn6V 5d1LdfAbAx3oGfbhJ1vurWZKPXLV2BtdrIFYMVF9RFl8I1nZpbAf87Gs6EfZIgdM/0Rw OZfaYRsAusAHGyWn7ZvqIWEEoxdkl63sXYDZObBKQqYdVTxFjw62jrDahhf1x6QjIBFM 3ZkOYmxuqaZQPDd8eJoWI3tve4/h/jAsBi6m4pkETGzLbZexbQseCOL4UfMY1heVRvYL 4gcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ajIOu4yG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hd42-20020a17090796aa00b006f3997f2199si676243ejc.328.2022.04.27.00.48.13; Wed, 27 Apr 2022 00:48:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ajIOu4yG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244919AbiDYTZn (ORCPT + 99 others); Mon, 25 Apr 2022 15:25:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235743AbiDYTZm (ORCPT ); Mon, 25 Apr 2022 15:25:42 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CA2151102A7 for ; Mon, 25 Apr 2022 12:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650914556; 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=mqmP98i3xVGOSE8p44wlqw/VP2O+Gc6FyNmdWMrFY9w=; b=ajIOu4yGeMt26ybDfoTda7autotNNi4+4FkzSYYAYWSggLg3NuhLhmJGkOATzmlhZzArE6 OVbXajk2X9nfBnSQxVy965xGx6ck90QVsQlfxhHA8f/JEnTpo6rgsnHRnVKpRt6l0f0KCY OfoLKyJ79JmrZ1n2ed2CYOla4XYCevI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-445-403Nb6SNMAybueqHbg33UA-1; Mon, 25 Apr 2022 15:22:33 -0400 X-MC-Unique: 403Nb6SNMAybueqHbg33UA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B17CB811E84; Mon, 25 Apr 2022 19:22:32 +0000 (UTC) Received: from fuller.cnet (ovpn-112-4.gru2.redhat.com [10.97.112.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B0FBF7AD9; Mon, 25 Apr 2022 19:22:26 +0000 (UTC) Received: by fuller.cnet (Postfix, from userid 1000) id 7049A416F574; Mon, 25 Apr 2022 16:21:59 -0300 (-03) Date: Mon, 25 Apr 2022 16:21:59 -0300 From: Marcelo Tosatti To: Aaron Tomlin Cc: Peter Zijlstra , Christoph Lameter , frederic@kernel.org, tglx@linutronix.de, 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 Message-ID: References: <20220422193647.3808657-1-atomlin@redhat.com> <20220425113909.u3smtztp66svlw4o@ava.usersys.com> <20220425132700.GK2731@worktop.programming.kicks-ass.net> <20220425141717.vw2jfnn3zp6c5ib2@ava.usersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220425141717.vw2jfnn3zp6c5ib2@ava.usersys.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=ham 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 Mon, Apr 25, 2022 at 03:17:17PM +0100, Aaron Tomlin wrote: > On Mon 2022-04-25 15:27 +0200, Peter Zijlstra wrote: > > On Mon, Apr 25, 2022 at 02:09:06PM +0200, Christoph Lameter wrote: > > > On Mon, 25 Apr 2022, Aaron Tomlin wrote: > > > > > > > Yes, in the context of nohz, this patch should ensure it, if required, when > > > > the idle tick is to be stopped. > > > > > > What I said was that it is generally useful. Even in the non NOHZ case. > > > > > > Folding the vmstat diffs *always* when entering idle prevents unnecessary > > > wakeups and processing in the future and also provides more accurate > > > counters for the VM allowing better decision to be made on reclaim. > > > > I'm thinking you're going to find a ton of regressions if you try it > > though; some workloads go idle *very* shortly, doing all this accounting > > is going to be counter-productive. > > Hi Peter, Christoph, > > Indeed. Which was why I decided, initially, against the general-purpose > case/or approach. Personally, I would prefer to keep this somewhat > restrictive to nohz. Is there anything that prevents a nohz full CPU from running an application with short and frequent idling? Note: commit a5183862e76fdc25f36b39c2489b816a5c66e2e5 Author: Yunfeng Ye Date: Thu May 13 01:29:16 2021 +0200 tick/nohz: Conditionally restart tick on idle exit In nohz_full mode, switching from idle to a task will unconditionally issue a tick restart. If the task is alone in the runqueue or is the highest priority, the tick will fire once then eventually stop. But that alone is still undesired noise. Therefore, only restart the tick on idle exit when it's strictly necessary. Signed-off-by: Yunfeng Ye Signed-off-by: Frederic Weisbecker Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/20210512232924.150322-3-frederic@kernel.org