Hello.. I hope I give good clue... On Jan 20, 2008 4:29 AM, Bulkmail <bulkmail@xxxxxxxxx> wrote: > I've been trying to find information about the effects of CONFIG_PREEMPT > on real time kernel threads. The description of CONFIG_PREEMPT says > "...allow preemption of user processes that are executing system > calls...". Most of the discussion seems to revolve around the > modification of the locking implementation. And the rest, I guess, talk about the way scheduler is called more often in return-from-interrupt-to-kernel-space context.... > Suppose: I have two or more kernel threads using the SCHED_FIFO policy > and they have differing priorities. Lets pretend the high priority > kthread is doing a down_interruptible() and the low priority kthread is > cheerfully executing. An interrupt fires and does an up() enabling the > high priority kthread.... Heck, lets say there's no interrupt and the > low priority kthread does the up().... Without compiling my kernel with > CONFIG_PREEMPT=y, will the high priority task get scheduled during the > up()? Or will the low priority task run until it yields? here are the general rules I know: a) Pick every runnable processes and b) Pick highest priority process. But SCHED_FIFO, IMHO, change the game a bit. Looking at the man page, I get impression that your low prio thread will keep running...until it explicitly sleeps...or block itself. BTW, yield() doesn't matter for SCHED_FIFO IMHO...SCHED_FIFO doesn't get time slice >In general, > I'm assuming the scheduler will always reschedule on return from > interrupts and after the release of a synchronization primitive? yes, CONFIG_PREEMPT=y does call scheduler on every return from interrupt..either to user space or kernel space. Don't forget you can also call schedule() by yourself. kernel level preemption can't happen if you call preempt_disable(), inside atomic/interrupt context....maybe other people can add this list... I hope it gives you a better sight... regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
