Messages in this thread | | | From | "" <> | Subject | Re: Utime and stime are less when getrusage (RUSAGE_THREAD) is executed on a tickless CPU. | Date | Fri, 21 May 2021 06:40:53 +0000 |
| |
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
| |