RE: [PATCH] perf_counter: Fix a race on perf_counter_ctx

[Peter Zijlstra]

On Tue, 2009-08-18 at 14:54 +0100, Metzger, Markus T wrote:

> Well, that would push out the limit a bit, but it would still be quite fragile.
> 
> Currently, I'm not sure that this (i.e. that the interrupt handling takes too long)
> is the underlying problem of the hangs that I'm seeing.
> 
> If it truly is, then I would go with the two-buffer approach. This would make the
> ISR itself predictably and reliably fast - at the expense of additional locked memory.

comment out that perf_counter_output() call and see what happens ;-)

> Do you think that this truly is the problem?
> How would the kernel react if interrupts were disabled for too long? I would definitely
> expect bad responsiveness, but can the kernel kill itself?

If we're branch tracing while processing the interrupt (not sure here),
then we might well generate enough output to generate a new interrupt,
causing back-to-back interrupts, basically DoSing the machine.


--
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/