Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752598AbdLSRXH (ORCPT <rfc822;w@1wt.eu>);
        Tue, 19 Dec 2017 12:23:07 -0500
Received: from resqmta-ch2-10v.sys.comcast.net ([69.252.207.42]:48094 "EHLO
        resqmta-ch2-10v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1750859AbdLSRXG (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Dec 2017 12:23:06 -0500
Date: Tue, 19 Dec 2017 11:23:03 -0600 (CST)
From: Christopher Lameter <cl@linux.com>
X-X-Sender: cl@nuc-kabylake
To: Frederic Weisbecker <frederic@kernel.org>
cc: LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Chris Metcalf <cmetcalf@mellanox.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Luiz Capitulino <lcapitulino@redhat.com>,
        "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
        Ingo Molnar <mingo@kernel.org>, Wanpeng Li <kernellwp@gmail.com>,
        Mike Galbraith <efault@gmx.de>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick
 offload
In-Reply-To: <CAFTL4hyd64a23Y0z7E2Cmay7Df795D52ouoh4T=uvtNnyBn=pA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1712191122100.18938@nuc-kabylake>
References: <1513653838-31314-1-git-send-email-frederic@kernel.org> <1513653838-31314-5-git-send-email-frederic@kernel.org> <alpine.DEB.2.20.1712191002480.16727@nuc-kabylake> <CAFTL4hyd64a23Y0z7E2Cmay7Df795D52ouoh4T=uvtNnyBn=pA@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-CMAE-Envelope: MS4wfBTtuZ30ckwDzQ5SkvXTlbQvddnyEpz75hN5RbHF4VbgAK+gKsO83NtbeIjPzQujwxSbEQzGtp75JA/NArS6oh76czpeHFlHH1pH5yulPs/7cjc6yh1m
 1Y13AsXfdaYqWGffBpKLC5eRXfKXtQe5QA1VaMwvyANjxzWFdEbPtx1YXIAcWgZ7cMxPLrv3ETefEFHI8DDcFfe3u5GkeB72ie2ZFn8n+i/Xo21MuT0kIApN
 U/VfpHJesMU2uko6jIxZT7lfrDJS0gvorsqMYex8cccD2s7Uw60cBKDDX50eTCxmB+WW8DpP8GB1O+1Uj8Fd/LJdeOIB+ZNm34k/WMkif/0v5K+4xoCs3jch
 9dQTvDv3fWLmmMfOfq2izj0P1qKo0NfuXFtYrG0nVqS83ozwUoQifBwGq9M9DHgno0dZDOrpm5IkUI9oZAcLc3pcgSZm0CSr5Kd5ikf5M/aBrR1EcyA9wEKC
 hYrAymsb9fjreLQc
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 424
Lines: 12

On Tue, 19 Dec 2017, Frederic Weisbecker wrote:

> > The vmstat processing required per cpu area access. How does that work if
> > the code is running on a remote processor?
>
> It seems that current::sched_class::task_tick() is ok with this, as it
> uses per runqueues or per task datas. And both are passed as
> arguments.

So I guess no vmstat processing is required? vmstat does not use per task
data but per cpu data.