David Laight wrote:

>On Mon, Apr 10, 2006 at 09:25:41AM +0200, Frank Kardel wrote:
>  
>
>>David,
>>
>>while you are at it, have you (or anyone else) considered
>>instrumenting locks (lockmanager & maybe even simple) for collecting
>>their locking time (min, max, accumulated, maybe even
>>a historam histogram)? During debugging interrupts and timecounter
>>implementation I got the impression that there may be
>>some bigger locks in the code as clock interrupts (100Hz rate)
>>vary by more 10% quite a few times. This has been observed on
>>MP systems.
>>    
>>
>
>no ....
>  
>
"no" for instrumenting locks or "no" for observing this on MP systems ?
I assume the "instrumenting locks" part.

>However if NetBSD does soft interrupt masking, it should be possible
>to measure the time between an IRQ being asserted and the real
>interrupt handler being called.
>
>In the past I used a logic analiser (in timing mode) to trigger when
>a device IRQ line was asserted for more than a few ms, wired the
>'trigger out' to the system NMI line, and thus got a system panic dump
>when the IRQ was masked for too long.  Turned out to be code that
>scrolled the VGA (text) console screen....
>  
>
Am I very wrong when I assume that this is unlikely to work
for lapic interrupts? I would expect the interrupt request line
from the lapic timer would only be accessible via major chip surgery
and some cooling issues on an AMD64 X2. Maybe there are other
accessible interrupt lines, but I am currently leaning towards "in line"
time stamping in order to get some grip what delays clock interrupts
over 10%.

>	David
>
>  
>
Frank