Messages in this thread | | | Date | Mon, 4 Apr 2005 22:47:25 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00 |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > actually, what priorities do the yielding tasks have? sched_yield() does > > not guarantee that the CPU will be given up, of if a highest-prio > > SCHED_FIFO task is in a yield() loop it will livelock the system. > > What scares me is the code in fs/inode.c with that > __wait_on_freeing_inode. Look at the code in find_inode and > find_inode_fast. Here you will see that they really are busy loops > with a yield in them, if the inode they are waiting on is I_FREEING or > I_CLEAR and the process doing this hasn't set I_LOCK. I haven't > looked much at this, but my kernel has livelocked on it.
ok, makes sense.
> Currently my fix is in yield to lower the priority of the task calling > yield and raise it after the schedule. This is NOT a proper fix. It's > just a hack so I can get by it and test other parts.
yeah, yield() is a quite RT-incompatible concept, which could livelock an upstream kernel just as much - if the task in question is SCHED_FIFO. Almost all yield() uses should be eliminated from the upstream kernel, step by step.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |