On 1/31/06, Gaurav Dhiman <gauravd.chd@xxxxxxxxx> wrote:
well .. i'm not sure of my understanding, but i'll discuss the ideas i have just for sharing them
i think we are considering this case, AFAIK you can register an interrupt handler and specify whether this interrupt handler runs with interrupts enabled or disabled. so we are just considering preemption of the interrupt context just if the interrupts where enabled while executing the interrupt handler
refer back to my previous reply .. i think this test is testing whether the interrupts where enabled or disabled while executing the kernel code before being here .. cli will not affect this CMIIW
another case where kernel preemption could be considered other than interrupt or exception is kernel threads, or syscalls executing where preempt is enabled
please CMIIW
thanks
MHD.Tayseer
On 1/30/06, Joe Knapka <jknapka@xxxxxxxxxxxxx> wrote:
> Gaurav Dhiman wrote:
>
> >Can someone explain me the following doubt:
> >
> >177 #ifdef CONFIG_PREEMPT
> >178 ENTRY(resume_kernel)
> >179 cli
> >180 cmpl $0,TI_preempt_count(%ebp) # non-zero preempt_count ?
> >181 jnz restore_all
> >182 need_resched:
> >183 movl TI_flags(%ebp), %ecx # need_resched set ?
> >184 testb $_TIF_NEED_RESCHED, %cl
> >185 jz restore_all
> >186 testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
> >187 jz restore_all
> >188 call preempt_schedule_irq
> >189 jmp need_resched
> >190 #endif
> >
> >I have observed that while returning from interrupts or exceptions
> >(ret_from intr() assembly code in entry.S), if we are moving back to
> >kernel execution path, we jump to 'resume_kernel', which in turn
> >checks the following things:
> >
> >1) Can we preempt (means current->preempt_count == 0)
> >2) if 1st point is true, we check, do we need to reschedule (means
> >current->need_resched is set).
> >3) if 2nd condition is also true (means we need to reschedule), then
> >we check are the intterupts disabled.
> >
> >If interrupts are disabled, we restore the registers and go back to
> >interrupted kernel execution path, else we call function
> >'preempt_schedule_irq()', which do the kernel preemption.
> >
> >My question is when we are deliberatly disabling the interrupts at
> >line 179 above, why do we check for interrupts disabled, they will
> >always be disabled, hence preemption will never be done while
> >returning from interrupts or exceptions.
> >
> >I think I am missing something .... please let me know the answer.
> >
> >
> Other places in the kernel jump directly to need_resched, so line 179
> may not have been executed in the code path that reached line 186.
well .. i'm not sure of my understanding, but i'll discuss the ideas i have just for sharing them
I was expecting this response from someone, well I that is fine.
I think I should repharse my question as follows:
Why dont we consider preemption while returning from interrupts or exceptions ??
i think we are considering this case, AFAIK you can register an interrupt handler and specify whether this interrupt handler runs with interrupts enabled or disabled. so we are just considering preemption of the interrupt context just if the interrupts where enabled while executing the interrupt handler
Whenever we will return to kernel execution path from exception or
interrupt, we will follow the path from 'resume_kernel', which
actually disables the interrupts by cli statement, due to which we
never consider preemption as possibility at check made at line 186
refer back to my previous reply .. i think this test is testing whether the interrupts where enabled or disabled while executing the kernel code before being here .. cli will not affect this CMIIW
while returning to kernel from exception or interrupt, why dont we
enable the interrupts (statment sti in place of cli) and do the
preemption if needed. Is there any harm in this ??
If we are not doing preemption or not considering it at all while
returing to kernel execution path from interrupts or exception, where
else we are considering the preemption. We definitely can not and are
not considering the preemption while returning from system call as in
that we will always be returing to user mode.
another case where kernel preemption could be considered other than interrupt or exception is kernel threads, or syscalls executing where preempt is enabled
please CMIIW
thanks
MHD.Tayseer
-Gaurav
>
> Cheers,
>
> -- JK
>
>
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
