linux-kernel - Re: Utime and stime are less when getrusage (RUSAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OSBPR01MB218357232513BC4EACD0FB59EB299@OSBPR01MB2183.jpnprd01.prod.outlook.com>
Date:   Fri, 21 May 2021 06:40:53 +0000
From:   "hasegawa-hitomi@...itsu.com" <hasegawa-hitomi@...itsu.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        "'fweisbec@...il.com'" <fweisbec@...il.com>,
        "'mingo@...nel.org'" <mingo@...nel.org>,
        "'tglx@...utronix.de'" <tglx@...utronix.de>,
        "'juri.lelli@...hat.com'" <juri.lelli@...hat.com>,
        "'vincent.guittot@...aro.org'" <vincent.guittot@...aro.org>
CC:     "'dietmar.eggemann@....com'" <dietmar.eggemann@....com>,
        "'rostedt@...dmis.org'" <rostedt@...dmis.org>,
        "'bsegall@...gle.com'" <bsegall@...gle.com>,
        "'mgorman@...e.de'" <mgorman@...e.de>,
        "'bristot@...hat.com'" <bristot@...hat.com>,
        "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>
Subject: Re: Utime and stime are less when getrusage (RUSAGE_THREAD) is
 executed on a tickless CPU.

Hi Peter and Frederic


> > Would be superfluous for CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y
> > architectures at the very least.
> > 
> > It also doesn't help any of the other callers, like for example procfs.
> > 
> > Something like the below ought to work and fix all variants I think. But
> > it does make the call significantly more expensive.
> > 
> > Looking at thread_group_cputime() that already does something like this,
> > but that's also susceptible to a variant of this very same issue; since
> > it doesn't call it unconditionally, nor on all tasks, so if current
> > isn't part of the threadgroup and/or another task is on a nohz_full cpu,
> > things will go wobbly again.
> > 
> > There's a note about syscall performance there, so clearly someone seems
> > to care about that aspect of things, but it does suck for nohz_full.
> > 
> > Frederic, didn't we have remote ticks that should help with this stuff?
> > 
> > And mostly I think the trade-off here is that if you run on nohz_full,
> > you're not expected to go do syscalls anyway (because they're sodding
> > expensive) and hence the accuracy of these sort of things is mostly
> > irrelevant.
> > 
> > So it might be the use-case is just fundamentally bonkers and we
> > shouldn't really bother fixing this.
> > 
> > Anyway?
> 
> Typing be hard... that should 'obviously' be reading: Anyone?


I understand that there is a trade-off between performance and accuracy
and that this issue may have already been discussed.
However, as Peter mentions, the process of updating sum_exec_runtime
just before retrieving information is already implemented in
thread_group_cputime() in the root of RUSAGE_SELF etc. So, I think
RUSAGE_THREAD should follow suit and implement the same process.

Thanks.
Hitomi Hasegawa