On 2/6/07, sandeep lahane <sandeep.lahane@xxxxxxxxx> wrote:
On 1/24/07, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
> Hi Rick
> > Hi,
> >
> > If an executing process is interrupted by an interrupt, is it ensured
> > that it won't get transferred to another idle CPU in the system??
> AFAIK, if the task is interrupted by interrupt, its state is still in
> TASK_RUNNING and isn't allowed to be rescheduled into another CPU.
> Another thing to watch is, while in interrupt handler (top half part),
> it is entering atomic condition and no preemption/reschedule is allowed
> in that situation. So IMHO, by looking into these, we can conclude that
> the process stays in the current CPU.
>
> However, after the CPU finishes the top halves of interrupt handler,
> thus leaving atomic situation and you are enabling full kernel level
> preemption, the scheduler is allowed to pick another process to be run
> and thus kicking out the currently running process in the CPU.
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
I know this list might not be best place to discuss this issue which
is becoming increasingly theoretical (at least my opinions/thoughts
were !). But now since this topic has started and came this far, I
would like to put forward my thoughts.
> AFAIK, if the task is interrupted by interrupt, its state is still in
> TASK_RUNNING and isn't allowed to be rescheduled into another CPU.
Here we can assume that the running tasks are locked to the cpu on
which they are running, so the task can not be migrated to other
cpu's.
> Another thing to watch is, while in interrupt handler (top half part),
> it is entering atomic condition and no preemption/reschedule is allowed
> in that situation. So IMHO, by looking into these, we can conclude that
> the process stays in the current CPU.
When ISR is executing preemption/reschedule is not allowed, agree. But
I was not talking about routing the interrupt to other cpus, rather
the task can be moved to other cpu's. I think, this can be
accomplished using some inter-processor interrupts i.e. before
executing the ISR for interrupt to be serviced make cpu-1 issue an
interrupt to cpu-n which is idle, now the ISR which will be invoked on
cpu-n should do the job of migrating the interrupted process to cpu-n.
After this is done, the ISR for cpu-1 should be executed. All this
would be easier if we have 4K stacks for each thread, ISR will have
separate stack.
This is just a high level overview of what I was thinking, for which I
have assumed few things etc. I don't know how much sense this makes
;-), particularly the part where I talk about migrating a task to
other cpu in an ISR etc. Let me know what you guys think about it.
--
Regards,
Sandeep.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
Can you clarify a little about how you plan to migrate the process from the ISR? I think only this is the gray part as you said, rest of the stuff seems logical. But I dont think this is how it is implemented in linux kernel. Probably you are talking about a new way of doing it. Experts on the list please enlighten.
-Pharaoh.
