Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 2005-04-04 at 22:00 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > So it is probably stuck in some spinning "yield" loop, which was the 
> > reason I was writing this test to begin with!  It's most likely also 
> > waiting for kjournald to do some work, and is starving it in a 
> > schedule or yield loop never actually going to sleep letting kjournald 
> > do the real work.
> 
> 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.

My custom kernel plays with dynamic priorities. That is tasks jump
around in their priorities based on different situations not part of the
normal linux kernel. So my kernel can find these cases easier since a
path where a process gets bumped up to a high priority happens more
often and causes preemption more often than the normal RT kernel. But
this situation can probably occur in the RT kernel and maybe even the
mainline kernel, since it only needs to have a RT FIFO task get blocked
here, and a lower priority task needing to run to change the state.

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. 

-- Steve