lkml.org 
[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.411 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site