Re: Utime and stime are less when getrusage (RUSAGE_THREAD) is executed on a tickless CPU.

["hasegawa-hitomi@fujitsu.com" <hasegawa-hitomi@fujitsu.com>]

Hi Mel, Peter, and Frederic

I'm sorry for the late reply.

> I don't think it's a straight-forward issue. I know we've had to deal with
> bugs in the past where the overhead of getting CPU usage statistics was
> high enough to dominate workloads that had self-monitoring capabilities to
> the extent the self-monitoring was counter-productive. It was particularly
> problematic when self-monitoring was being activated to find the source
> of a slowdown. I tend to agree with Peter here that the fix may be worse
> than the problem ultimately where workloads are not necessarily willing
> to pay the cost of accuracy and as he pointed out already, it's expected
> nohz_full tasks are avoiding syscalls as much as possible.

I understand that the use of syscall should be avoided as much as possible.
However, I think it is necessary to get accurate utime and stime
for performance tuning in nohz_full.
For example, how about introducing a new procfs entry or kernel configuration
so that the RUSAGE_THREAD process can switch the execution of
task_sched_runtime()? That way, It can leave it to the user to decide
whether to take performance or correctness.

Thanks.
Hitomi Hasegawa