lkml.org 
[lkml]   [2013]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 6/8] sched: task_sched_runtime introduce micro optimization
>> +#ifdef CONFIG_64BIT
>> + /*
>> + * 64-bit doesn't need locks to atomically read a 64bit value. So we
>> + * have two optimization chances, 1) when caller doesn't need
>> + * delta_exec and 2) when the task's delta_exec is 0. The former is
>> + * obvious. The latter is complicated. reading ->on_cpu is racy, but
>> + * this is ok. If we race with it leaving cpu, we'll take a lock. So
>> + * we're correct. If we race with it entering cpu, unaccounted time
>> + * is 0. This is indistinguishable from the read occurring a few
>> + * cycles earlier.
>> + */
>> + if (!add_delta || !p->on_cpu)
>> + return p->se.sum_exec_runtime;
>
> I'm not sure this is correct from an smp ordering POV. p->on_cpu may appear
> to be 0 whereas the task is actually running for a while and p->se.sum_exec_runtime
> can then be past the actual value on the remote CPU.

Quate form Paul's last e-mail

>Stronger:
>
>+#ifdef CONFIG_64BIT
>+ if (!p->on_cpu)
>+ return p->se.sum_exec_runtime;
>+#endif
>
>[ Or !p->on_cpu || !add_delta ].
>
>We can take the racy read versus p->on_cpu since:
> If we race with it leaving cpu: we take lock, we're correct
> If we race with it entering cpu: unaccounted time ---> 0, this is
>indistinguishable from the read occurring a few cycles earlier.

That said, even though we got slightly inaccurate current time, we
have no way to
know this is inaccurate. E.g. cpu clock saving feature bring us more
inaccuracy, but
we already live in such world.


\
 
 \ /
  Last update: 2013-06-21 11:21    [W:0.174 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site