[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.070 / U:8.416 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site