Messages in this thread | | | Date | Wed, 1 Mar 2000 15:19:03 -0500 (EST) | From | William Montgomery <> | Subject | Re: lowlatency-2.2.14-B1 + 2.2.14aa7 fixes crash, but... |
| |
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/
| |