[lkml]   [2008]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: regression introduced by - timers: fix itimer/many thread hang
    > > 	-	if (!->signal)
    > > + if (->exit_state)
    > > return;
    > Yes, unless I missed something again, this should work. I'll send
    > the (simple) patches soon, but I have no idea how to test them.

    That certainly will exclude the problem of crashing in the tick interrupt
    after exit_notify. Unfortunately, it's moving in an undesireable direction
    for the long run. That is, it loses from the accounting even more of the
    CPU time spent on the exit path.

    > However, I'm afraid there is another problem. On 32 bit cpus we can't
    > read "u64 sum_exec_runtime" atomically, and so thread_group_cputime()
    > can "overestimate" ->sum_exec_runtime by (up to) UINT_MAX if it races
    > with the thread which updates its per_cpu_ptr(.totals). This for example
    > means that check_process_timers() can fire the CPUCLOCK_SCHED timers
    > before time.
    > No?

    Yes, I think you're right. The best solution that comes to mind off hand
    is to protect the update/read of that u64 with a seqcount_t on 32-bit.


     \ /
      Last update: 2008-11-17 19:21    [W:0.021 / U:19.072 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site