Re: regression introduced by - timers: fix itimer/many thread hang

[Roland McGrath]

> But please note that currently this already happens for sub-threads (and
> if we protect ->signal with rcu too), the exiting sub-thread does not
> contribute to accounting after release_task(self). Also, when the last
> thread exits the process can be reaped by its parent, but after that
> the threads can still use CPU.

Understood (I think I mentioned this earlier).  All this is what makes it
seem potentially attractive in the long run to reorganize this more thoroughly.

> > 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.
> 
> Oh, but we need them to be per-cpu, and both read and write need memory
> barriers... Not that I argue, this will fix the problem of course, just
> I don't know how this impacts the perfomance.

I agree it's a sticky question.  Just the only thing I've thought of so far.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/