> From: William Lee Irwin III [mailto:[email protected]]
>
> William Lee Irwin III wrote:
> >>> I don't understand why you're obsessed with interrupts. Just run your
> >>> load and spray the scheduler latency stats out /proc/
>
> From: Chris Friesen [mailto:[email protected]]
> >> I'm obsessed with interrupts because it gives me a higher sampling
rate.
> >> I could set up and itimer for a recurring 10ms timeout and see how much
> >> extra I waited, but then I can only get 100 samples/sec. With
> >> /dev/rtc (on intel) you can get 20x more samples in the same amount
> >> of time.
>
> On Fri, May 09, 2003 at 05:39:03PM -0700, Perez-Gonzalez, Inaky wrote:
> > Okay, crazy idea here ...
> > You are talking about a bladed system, right? So probably you
> > have two network interfaces in there [it should work only with
> > one too].
> > What if you rip off the driver for the network interface and
> > create a new breed. Set an special link with a null Ethernet
> > cable and have one machine sending really short Ethernet frames
>
> This is ridiculous. Just make sure you're not sharing interrupts and
> count cycles starting at the ISR instead of wakeup and tag events
> properly if you truly believe that to be your metric. You, as the
> kernel, are notified whenever the interrupts occur and can just look
> at the time of day and cycle counts.
Well, I am only suggesting a way to _FORCE_ interrupts to happen
at a certain rate controllable by _SOMEBODY_, not as the system
gets them. Chris was concerned about not having a way to
_GENERATE_ interrupts at a certain rate.
What you are suggesting is the other part of the picture, how to
measure the latency and AFAICS, it is not part of the problem of
generating the interrupts.
I?aky P?rez-Gonz?lez -- Not speaking for Intel -- all opinions are my own
(and my fault)
From: William Lee Irwin III [mailto:[email protected]]
>> This is ridiculous. Just make sure you're not sharing interrupts and
>> count cycles starting at the ISR instead of wakeup and tag events
>> properly if you truly believe that to be your metric. You, as the
>> kernel, are notified whenever the interrupts occur and can just look
>> at the time of day and cycle counts.
On Mon, May 12, 2003 at 05:20:39PM -0700, Perez-Gonzalez, Inaky wrote:
> Well, I am only suggesting a way to _FORCE_ interrupts to happen
> at a certain rate controllable by _SOMEBODY_, not as the system
> gets them. Chris was concerned about not having a way to
> _GENERATE_ interrupts at a certain rate.
> What you are suggesting is the other part of the picture, how to
> measure the latency and AFAICS, it is not part of the problem of
> generating the interrupts.
It also seems somewhat pointless to measure it under artificial
conditions. Interrupts happen often anyway and you probably want to
measure the effects of real drivers and kernel subsystems on the time
it takes for the blocked task to resume in userspace for real loads.
By the time you've done up custom drivers and interrupt load generators
you've completely divorced whatever you're measuring from whatever will
affect runtime in the field.
-- wli