On 2/6/07, Pharaoh . <pharaoh137@xxxxxxxxx> wrote:
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.
Can someone throw more light on this? Let me know what you guys think. -- Regards, Sandeep. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
