On Wed, 1 Mar 2000, Andrea Arcangeli wrote:
> On Tue, 29 Feb 2000, William Montgomery wrote:
>
> >Why won't it trigger?
>
> We assume that the whole loop will take less than the tsk timeslice. If
> that's not true by running "goto again" unconditionally we would deadlock.
>
> If the loop will take less then the process timeslice, we know that after
> the schedule returned, we'll return from free_inodes before need_resched
> is set again to 1.
>
It is still not clear to me. Perhaps I am making a wrong assumption about
when schedule returns. In the scenario I described it seemed possible
for schedule to return before free_inodes was finished.
Process B is SCHED_FIFO waiting via sigpause().
Process A is SCHED_FIFO running and does signal() to Process B.
Process A waits in sigpause().
Process A run time in this case is very short, probably shorter that
free_inode loop.
> >[..] then does a signal() to a sleeping process [..] now the sleeping
> > process is need_resched [..]
>
> Sending a signal to "tsk" doesn't set "tsk->need_resched".
>
if a SCHED_OTHER process sends a signal to a waiting SCHED_FIFO process
shouldn't the SCHED_FIFO wakeup and run? What mechanism accomplishes
this?
Wm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:10 EST