Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1330497 > unrolled thread

Re: [PATCH 4/4] sched,time: only call account_{user,sys,guest,idle}_time once a jiffy

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/4] sched,time: only call  account_{user,sys,guest,idle}_time once a jiffy Frederic Weisbecker <fweisbec@gmail.com> - 2016-02-09 18:20 +0100
    Re: [PATCH 4/4] sched,time: only call  account_{user,sys,guest,idle}_time once a jiffy Rik van Riel <riel@redhat.com> - 2016-02-09 19:20 +0100
    Re: [PATCH 4/4] sched,time: only call  account_{user,sys,guest,idle}_time once a jiffy Rik van Riel <riel@redhat.com> - 2016-02-09 22:30 +0100

#1330497 — 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.

[toc] | [next] | [standalone]

#1330558

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-02-09 at 18:11 +0100, Frederic Weisbecker wrote:
> 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.
> 
> 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.

You are right that this code does not handle
short timeslices well.

However, I believe it does not have to, because
the scheduler already takes care of that.

At context switch time, the scheduler will call
vtime_common_task_switch, which calls
arch_vtime_task_switch, which handles precise
time accounting at task switch time.

The call chain is like this:

arch_vtime_task_switch
vtime_common_task_switch
vtime_task_switch
finish_task_switch
context_switch
__schedule

As you can see, the time accounting for shorter
running tasks is already handled by other code,
which means my patch should be ok.

-- 
All rights reversed

[toc] | [prev] | [next] | [standalone]

#1330659

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-02-09 at 18:11 +0100, Frederic Weisbecker wrote:
> 
> 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.

Looking over the code some more, you are right.

My changes to vtime_account_idle and
vtime_account_system will cause them to do
nothing a lot of the time, when called from
vtime_common_task_switch.

This causes a discrepancy between the time
accounted at task switch time, and the time
delta accounted later on.

I see two ways to fix this:
1) Always do fine granularity accounting at
   task switch time, and revert to coarser
   granularity at syscall time only. This may
   or may not be more accurate (not sure how
   much, or whether we care).
2) Always account at coarser granularity,
   like you suggest above. This has the
   advantage of leading to faster context
   switch times (no TSC reads).

I am happy to implement either.

Frederic, Thomas, Ingo, do you have a
preference between these approaches?

Would you like me to opt for the higher
performance option, or go for the potentially
higher accuracy one?


As an aside, I am wondering whether the call
to vtime_account_user() from
vtime_common_task_switch() ever does anything.

After all, the preceding call to vtime_account_system
would have already accounted all the CPU time that
passed to system time, and there will be no time left
to account to userspace.

Unless I am missing something, I suspect that line
can just go.

-- 
All rights reversed

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web