[LITMUS^RT] Questions on IPI

Hang Su hangsu.cs at gmail.com
Sat Nov 10 22:09:51 CET 2012


Hi all:

I want to know whether inter-processor interrupt at X86 is reliable and its
response time is bounded, such as *smp_send_reschedule and resched_cpu. *

For example, we have two cores and ticked-based scheduler, e.g., P-Fair,
does scheduling at each tick. Here, we assume that the last cpu, which
arrives at each tick, is responsible to call the scheduler,  e.g., CPU1 in
this example. When CPU0 arrives at t, it finds out it is not the last guy
and it has nothing to do. So, the kernel may iterate next sched _class and
pick up a process to run, e.g., init process and return to user space. When
CPU1 arrives at t, it does some calculations, select two processes and put
them on the top active queues on two CPUs. Since CPU1 is in kernel mode, I
set current need_resched to force it call schedule().  The question is the
expected context switch at CPU0 is sometimes  at (t+1) instead of at t(r),
even though CPU1 sends an IPI to CPU0 at t' by using *resched_cpu(0)*.
Since CPU0 may be in user space at t', how it responds a IPI in x86
architecture and its responds time( t(r) - t' ) is bounded or not. Based on
my tracing info, the context switch at CPU0, which is supposed to occur at
t(r), occurs at t+1. I guess it is possible CPU0 automatically call
schedule() when it returns back to user space from a tick-interrupt handler
(t+1). At t', is that possible CPU0 ignore this IPI from CPU1 or it delays
this IPI and response it at unpredictable time?


CPU0      |t|        t'       t(r)     |t+1|
                        /|\
                         |
                         |
CPU1         |t|     |                         |t+1|
                       ready


Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20121110/e9f3b07e/attachment.html>


More information about the litmus-dev mailing list