[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
>-----Original Message-----
>From: Peter Zijlstra []
>Sent: Tuesday, August 18, 2009 4:02 PM
>To: Metzger, Markus T
>Cc: Ingo Molnar;;;; linux-
>; Paul Mackerras
>Subject: RE: [PATCH] perf_counter: Fix a race on perf_counter_ctx
>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 ;-)

That's what I did more or less.
When I ignore the buffer size and sample 10 records, it seems to work.
When I sample 1000 records, the kernel hangs.

But this does not automatically mean that the increased time in the ISR is
directly causing the hang, does it?

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

We call perf_disable() when entering the ISR and perf_enable() when exiting.


Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

 \ /
  Last update: 2009-08-18 16:21    [W:0.268 / U:0.928 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site