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 D7D3EC433FE for ; Wed, 4 May 2022 09:36:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E30B6B0071; Wed, 4 May 2022 05:36:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 093526B0073; Wed, 4 May 2022 05:36:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9C056B0074; Wed, 4 May 2022 05:36:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D68ED6B0071 for ; Wed, 4 May 2022 05:36:17 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A2FD720EC6 for ; Wed, 4 May 2022 09:36:17 +0000 (UTC) X-FDA: 79427554794.11.4A6E72D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id BA2331C0093 for ; Wed, 4 May 2022 09:36:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651656976; 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=g6g2UJy+0nwhmO5/tF8oPdW8Lnfz1wSfTmKwEMghbcA=; b=VrYgx7ma9fEpqOU612u7RRWnr0xsYZtBC9VCZ03hpa8d9Yy+nM3zbsREDbnOtf+m17V74A fvVxm4R5d9UcvHhEeICvfDc/U0hdUboSp3ziwfT44vCydT3od68bYE4fq+q3D3cm995NQM Tlpu2G/4mQf7L+s4Ztri/O6r6zIX0Jk= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-113-MTchM-afO_q9JU26b5aO0A-1; Wed, 04 May 2022 05:32:35 -0400 X-MC-Unique: MTchM-afO_q9JU26b5aO0A-1 Received: by mail-wm1-f72.google.com with SMTP id m26-20020a7bcb9a000000b0039455e871b6so408268wmi.8 for ; Wed, 04 May 2022 02:32:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=g6g2UJy+0nwhmO5/tF8oPdW8Lnfz1wSfTmKwEMghbcA=; b=J5AN4jn+kpjaLS9+ME/HFlrzIityfLgkT3kdej7vOzqaHHWyJpenYsORN4/9aDIwK6 1eQRt/xZZGvgXQAz0mxLvPyE5YuNTzTWfLIMS2oRwF8Awe844sFMTONFseEnc7pPzq7k Rfez1pc6Di9gnHTmT+r24WVs1ICp8HE/+OcFbpUmfm7kCf+wtkjtz85R9FFRs8ZyGTKF uuaueJ0SUpAeRqTazcyFAnhQMhjDOHyKZfH721eda6Xf0J28dFYPLP8g0gCafcqdlZhJ pE0y694ELsJC5OCRsGD50cQ9vvQbyLLmxSJ9EcbpynA6j3yLbTfDCCx/n0YFv+tFDoEK 5/aw== X-Gm-Message-State: AOAM532jQp3+j9UCCuVYL/kbg3wxJ0v7G8xArBFtf2j7+XoAQtfJe2Px jspnd0mDUWfh1j7ZaNX5oY0bw1lBZsQ01/5oXGSsxt4lt+RQViGoy3noETwcVRlYhgHbEoTLACe lZimCCynFhg== X-Received: by 2002:a05:600c:4ecc:b0:394:3250:d88c with SMTP id g12-20020a05600c4ecc00b003943250d88cmr6688150wmq.105.1651656752922; Wed, 04 May 2022 02:32:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzO+pbxaczdRjaRn57aZ40kzSJJ6kjffsdlMDg10f1bqbYBn8iIHq0NrVydrrKVdtoougHgAA== X-Received: by 2002:a05:600c:4ecc:b0:394:3250:d88c with SMTP id g12-20020a05600c4ecc00b003943250d88cmr6688115wmq.105.1651656752625; Wed, 04 May 2022 02:32:32 -0700 (PDT) Received: from localhost (cpc111743-lutn13-2-0-cust979.9-3.cable.virginm.net. [82.17.115.212]) by smtp.gmail.com with ESMTPSA id j28-20020a05600c1c1c00b003942a244f39sm3382841wms.18.2022.05.04.02.32.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 May 2022 02:32:31 -0700 (PDT) Date: Wed, 4 May 2022 10:32:30 +0100 From: Aaron Tomlin To: Marcelo Tosatti Cc: frederic@kernel.org, cl@linux.com, tglx@linutronix.de, mingo@kernel.org, peterz@infradead.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: <20220504093230.xmksdyagcpgs7sjt@ava.usersys.com> X-PGP-Key: http://pgp.mit.edu/pks/lookup?search=atomlin%40redhat.com X-PGP-Fingerprint: 7906 84EB FA8A 9638 8D1E 6E9B E2DE 9658 19CC 77D6 References: <20220422193647.3808657-1-atomlin@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Stat-Signature: wmjeje9kuonbkrezkcgggdbjt6y7ddak X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BA2331C0093 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VrYgx7ma; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of atomlin@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=atomlin@redhat.com X-HE-Tag: 1651656971-377631 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 Thu 2022-04-28 15:10 -0300, Marcelo Tosatti wrote: > So you are syncing the vmstats on every system call return: Hi Marcelo, Sorry about the delay! No - indeed, that would be too expensive. If I understand correctly, Peter Zijlstra's feedback was in response to a previous suggestion made: "Could we *always* fold the vmstat counters when entering idle mode? ..." I think an exception should be made for the adaptive-tick mode/or a nohz_full CPU case when the scheduling-clock tick is stopped. Also, I feel correctness is key, as previously indicated since a significant divergence can impact memory reclaim code. > Have you measured performance of any system call heavy application > with this change? Unfortunately not. That being said, the aforementioned test and work will only take place under a nohz_full CPU and if the tick is stopped. So this should be somewhat limited, no? > Then the comment on why its so slow: > > "This loop is quite heavy. Maybe reducing the data necessary to be read > to a couple of cachelines would improve it considerably." > > The comment: > > "Is there anything that prevents a nohz full CPU from running an > application with short and frequent idling?" > > Is confusing and can be ignored. Understood. Kind regards, -- Aaron Tomlin