On Fri, Aug 14, 2009 at 7:12 AM, Mohammed Gamal<m.gamal005@xxxxxxxxx> wrote: > On Fri, Aug 14, 2009 at 11:25 AM, Mulyadi > Santosa<mulyadi.santosa@xxxxxxxxx> wrote: >> On Fri, Aug 14, 2009 at 12:15 PM, Michael >> Blizek<michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >>> Hi! >>> >>> On 00:08 Fri 14 Aug , Mohammed Gamal wrote: >>> >>> ... >>> >>>> As far as I understood, Michi's answer explains why and when the >>>> kernel *can* get preempted, however what I really want to know is when >>>> and where kernel preemption is *triggered*. Please correct me if I did >>>> misunderstand anything. >>> >>> It is triggered by the timer interrupt. This is an interrupt which fires >>> periodically on configureable intervals. It does not only preempt the kernel, >>> but user space processes as well. If it fires, the kernel will enter the >>> scheduler and decide what to run next. >> >> In addition, IIRC: >> - every return from hard interrupt, either back to kernel space (if >> kernel level preemption is enabled) or to user space triggers >> preemption checking. >> >> - going back from kernel space to user space triggers preemption checking. >> >> >> -- >> regards, >> >> Mulyadi Santosa >> Freelance Linux trainer >> blog: the-hydra.blogspot.com >> > > Thanks guys, > Any pointers to where this is done in the kernel source? I'm a little > bit lost there. > > Regards, > Mohammed I have not looked into the details of CONFIG_PREEMPT before. When it is enabled, does it mean every interrupt that invokes the scheduler can preempt a task, even if it is in kernel space. Or does it mean there is a API that allows a task to say "I'm high priority, run me at the next interrupt even if the kernel is what was interrupted?" If the latter, I believe the question is "What's the API to do that?" If the former, the question makes no sense. Greg -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
