lkml.org 
[lkml]   [2009]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [PATCH] perf_counter: Fix a race on perf_counter_ctx
From
Date
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.




\
 
 \ /
  Last update: 2009-08-18 16:05    [W:0.082 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site