Messages in this thread | | | Date | Tue, 9 Feb 2016 18:11:40 +0100 | From | Frederic Weisbecker <> | Subject | Re: [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.
| |