On Tue, Feb 02, 2016 at 12:19:46PM -0500, [email protected] wrote: > From: Rik van Riel <[email protected]> > > 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.
