> 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
(5/1/13 7:00 AM), Peter Zijlstra wrote:
> On Mon, Apr 29, 2013 at 11:17:17PM -0400, kosaki.motoh...@gmail.com wrote:
>> From: KOSAKI Motohiro
>>
>> rq lock in task_sched_runtime() is necessary for two reasons. 1)
>> accessing se.sum_exec_runtime is inatomic on 32bit and 2)
>> do_task_delta_exec()
On Wed, May 1, 2013 at 4:00 AM, Peter Zijlstra wrote:
> On Mon, Apr 29, 2013 at 11:17:17PM -0400, kosaki.motoh...@gmail.com wrote:
>> From: KOSAKI Motohiro
>>
>> rq lock in task_sched_runtime() is necessary for two reasons. 1)
>> accessing se.sum_exec_runtime is inatomic on 32bit and 2)
>> do_tas
On Mon, Apr 29, 2013 at 11:17:17PM -0400, kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro
>
> rq lock in task_sched_runtime() is necessary for two reasons. 1)
> accessing se.sum_exec_runtime is inatomic on 32bit and 2)
> do_task_delta_exec() require it.
>
> And then, 64bit can avoid hol
From: KOSAKI Motohiro
rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is inatomic on 32bit and 2)
do_task_delta_exec() require it.
And then, 64bit can avoid holds rq lock when add_delta is false.
Signed-off-by: KOSAKI Motohiro
---
kernel/sched/co
5 matches
Mail list logo