* Linux kernel preemption (kernel 2.6 of course) [not found] <20031108003029.BF9DB5F711@attila.bofh.it> @ 2003-11-08 1:27 ` Oleg OREL 2003-11-08 8:05 ` Ingo Molnar 2003-11-09 0:21 ` Robert Love 0 siblings, 2 replies; 3+ messages in thread From: Oleg OREL @ 2003-11-08 1:27 UTC (permalink / raw) To: linux-kernel I was browsing linux kernel to undetsnand how kernel preemption does work. I was hacking around schedulee_tick and other functions called out of timer interrupt and was unable to found any call to schedule() or switch_to() to peempt currently running task, instead just mangling around current and inactive runqueues. That leads me to a thought that currently running task wont be preempted within time-tick, instead it might happends in the next call to preempt_schedule out of spin_lock for instance. ===== Oleg OREL TEL: +1 925 244-1127 CELL: +1 916 337-0608 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Linux kernel preemption (kernel 2.6 of course) 2003-11-08 1:27 ` Linux kernel preemption (kernel 2.6 of course) Oleg OREL @ 2003-11-08 8:05 ` Ingo Molnar 2003-11-09 0:21 ` Robert Love 1 sibling, 0 replies; 3+ messages in thread From: Ingo Molnar @ 2003-11-08 8:05 UTC (permalink / raw) To: Oleg OREL; +Cc: linux-kernel On Fri, 7 Nov 2003, Oleg OREL wrote: > I was browsing linux kernel to undetsnand how kernel preemption does > work. I was hacking around schedulee_tick and other functions called out > of timer interrupt and was unable to found any call to schedule() or > switch_to() to peempt currently running task, instead just mangling > around current and inactive runqueues. the timer interrupt indeed cannot reschedule because interrupt contexts must never schedule. But the timer interrupt does have the ability to reschedule the currently running task, via setting the 'need resched' flag: set_tsk_need_resched(p); this flag then gets detected by the entry.S 'return from interrupt' code [right when the timer irq returns] which then calls schedule(). ingo ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Linux kernel preemption (kernel 2.6 of course) 2003-11-08 1:27 ` Linux kernel preemption (kernel 2.6 of course) Oleg OREL 2003-11-08 8:05 ` Ingo Molnar @ 2003-11-09 0:21 ` Robert Love 1 sibling, 0 replies; 3+ messages in thread From: Robert Love @ 2003-11-09 0:21 UTC (permalink / raw) To: oleg_orel; +Cc: linux-kernel On Fri, 2003-11-07 at 20:27, Oleg OREL wrote: > I was browsing linux kernel to undetsnand how kernel preemption does > work. I was hacking around schedulee_tick and other functions called > out of timer interrupt and was unable to found any call to schedule() > or switch_to() to peempt currently running task, instead just mangling > around current and inactive runqueues. Linux rarely forces a reschedule, because interrupt handlers cannot block. So we have the need_resched variable (in 2.6, a flag in thread_info) to note if a reschedule is pending. The scheduler is then invoked asap. > That leads me to a thought that currently running task wont be > preempted within time-tick, instead it might happends in the next call > to preempt_schedule out of spin_lock for instance. Yes, this is true. With kernel preemption enabled, if a task is executing in the kernel, and an interrupt occurs that marks need_resched, the reschedule will take place immediately on return from interrupt UNLESS a lock is held. In which case the reschedule will occur when the lock is released (specifically, when preempt_count hits zero). Without kernel preemption, the reschedule will not take place until the executing task in the kernel blocks and a return to user-space occurs. Robert Love ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-11-09 0:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20031108003029.BF9DB5F711@attila.bofh.it>
2003-11-08 1:27 ` Linux kernel preemption (kernel 2.6 of course) Oleg OREL
2003-11-08 8:05 ` Ingo Molnar
2003-11-09 0:21 ` Robert Love
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox