Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 3fE8DJJidGkQm33ZVoDDIPSVZSIadk7syZ+NHEs8H3JZnjLOh0hB7FA62y90AqghxA8n3v3LMQ
 8q/1eyT4X35GmC1VUKBkkHKwIQt1K7ehEEsog0RJ5VwoyVtuO6m11Al1kzwD+nffR2ydAviy9x
 n8EDrAdHyS/gyljiORW4t/EyuVs7tJPR8TPO8jKj/nIwnFacDm1GsOmY56NjbA8hqOVhL4vZbK
 4Vrii5Tah6jpRMBrGfyjI5rEslaHp8Xvk1f3vTGUg0BGbwNXo1eSomsc4/2JqvmQO5gTvTXt/5
 Vqw=
From:   "hasegawa-hitomi@fujitsu.com" <hasegawa-hitomi@fujitsu.com>
To:     Peter Zijlstra <peterz@infradead.org>,
        "'fweisbec@gmail.com'" <fweisbec@gmail.com>,
        "'mingo@kernel.org'" <mingo@kernel.org>,
        "'tglx@linutronix.de'" <tglx@linutronix.de>,
        "'juri.lelli@redhat.com'" <juri.lelli@redhat.com>,
        "'vincent.guittot@linaro.org'" <vincent.guittot@linaro.org>
CC:     "'dietmar.eggemann@arm.com'" <dietmar.eggemann@arm.com>,
        "'rostedt@goodmis.org'" <rostedt@goodmis.org>,
        "'bsegall@google.com'" <bsegall@google.com>,
        "'mgorman@suse.de'" <mgorman@suse.de>,
        "'bristot@redhat.com'" <bristot@redhat.com>,
        "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: Utime and stime are less when getrusage (RUSAGE_THREAD) is
 executed on a tickless CPU.
Thread-Topic: Utime and stime are less when getrusage (RUSAGE_THREAD) is
 executed on a tickless CPU.
Thread-Index: AddG3PD5Dm9CD2RNQ7+TrQrb7bYc8AE2IspgAAJjxoAAIq+F+AARwywAAAAeGgAAXleiXg==
Date:   Fri, 21 May 2021 06:40:53 +0000
Message-ID: <OSBPR01MB218357232513BC4EACD0FB59EB299@OSBPR01MB2183.jpnprd01.prod.outlook.com>
References: <OSBPR01MB21837C8931D90AE55AF4A955EB529@OSBPR01MB2183.jpnprd01.prod.outlook.com>
 <OSBPR01MB2183384B29F6291EB7C0BB81EB2C9@OSBPR01MB2183.jpnprd01.prod.outlook.com>
 <YKN5cQpFSdsgBlBU@hirez.programming.kicks-ass.net>
 <OSBPR01MB21835E55331FCAE6F75E8332EB2B9@OSBPR01MB2183.jpnprd01.prod.outlook.com>
 <YKTZag/E8AaOtVT0@hirez.programming.kicks-ass.net>,<YKTaNJ7r/sHnwb5W@hirez.programming.kicks-ass.net>
In-Reply-To: <YKTaNJ7r/sHnwb5W@hirez.programming.kicks-ass.net>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: af12c6ee-e3e2-47a8-2039-08d91c236160
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2021 06:40:53.1639
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a19f121d-81e1-4858-a9d8-736e267fd4c7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: g+FwqpSiHpKjAJ6/zUDazr7rrw8daN/hXgL/PWE9CsCE+R6fEhWs3zomB9vmiFE+tOKVo8NC4v+3GGrBIa9RMO0jCP4qIm64plAeVbN2xH0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS0PR01MB5747
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Peter and Frederic=0A=
=0A=
=0A=
> > Would be superfluous for CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=3Dy=0A=
> > architectures at the very least.=0A=
> > =0A=
> > It also doesn't help any of the other callers, like for example procfs.=
=0A=
> > =0A=
> > Something like the below ought to work and fix all variants I think. Bu=
t=0A=
> > it does make the call significantly more expensive.=0A=
> > =0A=
> > Looking at thread_group_cputime() that already does something like this=
,=0A=
> > but that's also susceptible to a variant of this very same issue; since=
=0A=
> > it doesn't call it unconditionally, nor on all tasks, so if current=0A=
> > isn't part of the threadgroup and/or another task is on a nohz_full cpu=
,=0A=
> > things will go wobbly again.=0A=
> > =0A=
> > There's a note about syscall performance there, so clearly someone seem=
s=0A=
> > to care about that aspect of things, but it does suck for nohz_full.=0A=
> > =0A=
> > Frederic, didn't we have remote ticks that should help with this stuff?=
=0A=
> > =0A=
> > And mostly I think the trade-off here is that if you run on nohz_full,=
=0A=
> > you're not expected to go do syscalls anyway (because they're sodding=
=0A=
> > expensive) and hence the accuracy of these sort of things is mostly=0A=
> > irrelevant.=0A=
> > =0A=
> > So it might be the use-case is just fundamentally bonkers and we=0A=
> > shouldn't really bother fixing this.=0A=
> > =0A=
> > Anyway?=0A=
> =0A=
> Typing be hard... that should 'obviously' be reading: Anyone?=0A=
=0A=
=0A=
I understand that there is a trade-off between performance and accuracy=0A=
and that this issue may have already been discussed.=0A=
However, as Peter mentions, the process of updating sum_exec_runtime=0A=
just before retrieving information is already implemented in=0A=
thread_group_cputime() in the root of RUSAGE_SELF etc. So, I think=0A=
RUSAGE_THREAD should follow suit and implement the same process.=0A=
=0A=
Thanks.=0A=
Hitomi Hasegawa=