Messages in this thread | | | Subject | RE: [PATCH] perf_counter: Fix a race on perf_counter_ctx | From | Peter Zijlstra <> | Date | Tue, 18 Aug 2009 16:01:31 +0200 |
| |
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.
| |