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:3.058 / U:0.900 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site