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;
Date:   Mon, 25 Apr 2022 11:57:31 -0300
From:   Marcelo Tosatti <mtosatti@redhat.com>
To:     Christoph Lameter <cl@gentwo.de>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Aaron Tomlin <atomlin@redhat.com>, 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: <Yma229h8meLFvCI1@fuller.cnet>
References: <20220422193647.3808657-1-atomlin@redhat.com>
 <alpine.DEB.2.22.394.2204250919400.2367@gentwo.de>
 <20220425113909.u3smtztp66svlw4o@ava.usersys.com>
 <alpine.DEB.2.22.394.2204251406370.13839@gentwo.de>
 <20220425132700.GK2731@worktop.programming.kicks-ass.net>
 <alpine.DEB.2.22.394.2204251603570.25814@gentwo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alpine.DEB.2.22.394.2204251603570.25814@gentwo.de>
Precedence: bulk

On Mon, Apr 25, 2022 at 04:06:04PM +0200, Christoph Lameter wrote:
> On Mon, 25 Apr 2022, Peter Zijlstra wrote:
> 
> > > 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.
> 
> Well there is usually not much to do in terms of accounting. 

static int refresh_cpu_vm_stats(bool do_pagesets)
{
        struct pglist_data *pgdat;
        struct zone *zone;
        int i;
        int global_zone_diff[NR_VM_ZONE_STAT_ITEMS] = { 0, };
        int global_node_diff[NR_VM_NODE_STAT_ITEMS] = { 0, };
        int changes = 0;

        for_each_populated_zone(zone) {
                struct per_cpu_zonestat __percpu *pzstats = zone->per_cpu_zonestats;
#ifdef CONFIG_NUMA
                struct per_cpu_pages __percpu *pcp = zone->per_cpu_pageset;
#endif

                for (i = 0; i < NR_VM_ZONE_STAT_ITEMS; i++) {
                        int v;

                        v = this_cpu_xchg(pzstats->vm_stat_diff[i], 0);
                        if (v) {

This loop is quite heavy. Maybe reducing the data necessary to be read
to a couple of cachelines would improve it considerably.

> If there are
> a lot of updates then it is worthwhile because if the numbers are off too
> much then the VM has trouble assessing its own situation.
> 
> It may depend though on how long the idle periods are. Do we have
> statistics on the duration? Always folding the vmstat deltas may also
> increase the length of the idle periods.

"Products such as the Intel® Optane™ SSD DC P4800X series have a read and write
latency of 10 microseconds, compared with a write latency of about 220 
microseconds for a typical NAND flash SSD."