lkml.org 
[lkml]   [2016]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] sched,time: only call account_{user,sys,guest,idle}_time once a jiffy
On Tue, Feb 02, 2016 at 12:19:46PM -0500, riel@redhat.com wrote:
> From: Rik van Riel <riel@redhat.com>
>
> After removing __acct_update_integrals from the profile,
> native_sched_clock remains as the top CPU user. This can be
> reduced by only calling account_{user,sys,guest,idle}_time
> once per jiffy for long running tasks on nohz_full CPUs.
>
> This will reduce timing accuracy on nohz_full CPUs to jiffy
> based sampling, just like on normal CPUs.

I wonder if that assumption is actually right.

With tick based sampling, we indeed have a statistical accounting
which precision is based on HZ. Now the time accounted when the tick
fires is always a single unit: 1 jiffy. So we have a well distributed
accounting value because it's constant and based on the probability of
a periodic event.

So for any T_slice being a given cpu timeslice (in secs) executed between
two ring switch (user <-> kernel), we are going to account: 1 * P(T_slice*HZ)
(P() stand for probability here).

Now after this patch, the scenario is rather different. We are accounting the
real time spent in a slice with a similar probablity.
This becomes: T_slice * P(T_slice*HZ).

So it seems it could result into logarithmic accounting: timeslices of 1 second
will be accounted right whereas repeating tiny timeslices may result in much lower
values than expected.

To fix this we should instead account jiffies_to_nsecs(jiffies - t->vtime_jiffies).
Well, that would drop the use of finegrained clock and even the need of nsecs based
cputime. But why not if we still have acceptable result for much more performances.

I don't know if all the above actually makes sense. I suck at maths so I may well be
wrong.

\
 
 \ /
  Last update: 2016-02-09 18:21    [W:0.090 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site