lkml.org 
[lkml]   [2021]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Utime and stime are less when getrusage (RUSAGE_THREAD) is executed on a tickless CPU.
Date
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
\
 
 \ /
  Last update: 2021-05-21 08:49    [W:0.112 / U:2.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site