hi,
i am trying to find out the interrupt latency for the linux-2.6.14, can anyone tell me what is the procedure to test latency and the code used to test it? please help me out to achieve this job....
What exactly do you understand by interrupt latency because I have something that might help.
Let me explain first what my "benchmark" measures and how I see the whole picture so you can decide if its of any help or not.
When a thread issues an I/O request via the kernel system call (read()/ write() ops for example), if the device driver that handles the system call cannot satisfy the request for data, puts the calling thread on a wait queue. This action puts the requesting thread to sleep so that it will not be eligible to run while waiting for the device to provide data.
The driver then insures that the I/O request will generate an interrupt when the device completes the request and the driver returns control to the kernel. At this point, the requesting thread is asleep and the device is performing the requested I/O.
The kernel runs all the eligible threads that is all thread marked as being able to execute. At this point the device will complete the request and assert an interrupt line. This will cause an ISR to run in the kernel, which runs the device driver’s interrupt handler. The handler will remove the thread from the driver wait queue, making it ready to run .The kernel code will check to see if the thread that was awakened can run and if it can the kernel will set the need_reched flag into the current task structure.
When the kernel gets to a point where schedule is allowed it will note that need_resched was set and will call the function schedule() which will determine what thread should run next thus serving the I/O request.
The amount of time that elapses from when the interrupt is asserted to when the thread that issued the I/O request runs is called kernel response time.
The kernel response time is the sum of the following times :
Now, the interrupt latency (what you might be interested in) is the amount of time that elapses between the physical interrupt signal being asserted and the ISR running. This parameter is completely hardware specific and I'm not sure could be measured by software. Probably what you would need in this case is an oscilloscope or a logical analyzer to probe the interrupt signals in hardware.
Interrupt handler duration varies completely on how the handler.
Scheduler latency is the amount of time elapsed between the ISR completing and the scheduling function being run.
Scheduling duration is the amount of time spent inside the scheduler deciding which task should be run next.
My "benchmark" is in fact a kernel module that measures the scheduler lateny.
A software timer generates interrupts every 50ms. A kernel thread is also created, and put in a TASK_INTERRUPTIBLE state.
Then the thread invokes the scheduler by calling the schedule () function.
When the interrupt handler is executed the time is read firs and then the thread which was previously put to sleep is waken up. When the scheduler gets to execute the thread again I get the time again and output the difference.
If thats what you're looking for I can send you the sources.
The amount of time that elapses from when the interrupt is asserted to when the thread that issued the I/O request runs is called kernel response time.
how can test the kernel response time.
Hey, What exactly do you
Hey,
What exactly do you understand by interrupt latency because I have something that might help.
Let me explain first what my "benchmark" measures and how I see the whole picture so you can decide if its of any help or not.
When a thread issues an I/O request via the kernel system call (read()/ write() ops for example), if the device driver that handles the system call cannot satisfy the request for data, puts the calling thread on a wait queue. This action puts the requesting thread to sleep so that it will not be eligible to run while waiting for the device to provide data.
The driver then insures that the I/O request will generate an interrupt when the device completes the request and the driver returns control to the kernel. At this point, the requesting thread is asleep and the device is performing the requested I/O.
The kernel runs all the eligible threads that is all thread marked as being able to execute. At this point the device will complete the request and assert an interrupt line. This will cause an ISR to run in the kernel, which runs the device driver’s interrupt handler. The handler will remove the thread from the driver wait queue, making it ready to run .The kernel code will check to see if the thread that was awakened can run and if it can the kernel will set the need_reched flag into the current task structure.
When the kernel gets to a point where schedule is allowed it will note that need_resched was set and will call the function schedule() which will determine what thread should run next thus serving the I/O request.
The amount of time that elapses from when the interrupt is asserted to when the thread that issued the I/O request runs is called kernel response time.
The kernel response time is the sum of the following times :
Interrupt latency
Interrupt handler duration
Scheduler Latency
Scheduling Duration
Now, the interrupt latency (what you might be interested in) is the amount of time that elapses between the physical interrupt signal being asserted and the ISR running. This parameter is completely hardware specific and I'm not sure could be measured by software. Probably what you would need in this case is an oscilloscope or a logical analyzer to probe the interrupt signals in hardware.
Interrupt handler duration varies completely on how the handler.
Scheduler latency is the amount of time elapsed between the ISR completing and the scheduling function being run.
Scheduling duration is the amount of time spent inside the scheduler deciding which task should be run next.
My "benchmark" is in fact a kernel module that measures the scheduler lateny.
A software timer generates interrupts every 50ms. A kernel thread is also created, and put in a TASK_INTERRUPTIBLE state.
Then the thread invokes the scheduler by calling the schedule () function.
When the interrupt handler is executed the time is read firs and then the thread which was previously put to sleep is waken up. When the scheduler gets to execute the thread again I get the time again and output the difference.
If thats what you're looking for I can send you the sources.
Cheers
send me the source for kernel response time
The amount of time that elapses from when the interrupt is asserted to when the thread that issued the I/O request runs is called kernel response time.
how can test the kernel response time.
Regards
bheem