lkml.org 
[lkml]   [2000]   [Feb]   [29]   [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 Mon, 28 Feb 2000, Andrea Arcangeli wrote:

    > This is the diff for the free_inode conditional schedule. The spin_unlock
    > thing probably couldn't harm since such code is all under the big kernel
    > lock too in 2.2.x.
    >
    > --- 2.2.14/fs/inode.c Fri Jan 7 18:19:18 2000
    > +++ /tmp/inode.c Mon Feb 28 19:57:05 2000
    > @@ -347,7 +347,9 @@
    > {
    > struct list_head *entry;
    > int found = 0;
    > + int resched = 0;
    >
    > + again:
    > entry = inode_in_use.next;
    > while (entry != &inode_in_use) {
    > struct list_head *tmp = entry;
    > @@ -361,6 +363,18 @@
    > list_add(tmp, freeable);
    > list_entry(tmp, struct inode, i_list)->i_state = I_FREEING;
    > found++;
    > +
    > + if (current->need_resched && !resched) {
    > + INODE(tmp)->i_count++;
    > + spin_unlock(&inode_lock);
    > +
    > + schedule();
    > + iput(INODE(tmp));
    > +
    > + spin_lock(&inode_lock);
    > + resched = 1;
    > + goto again;
    > + }
    > }
    >
    > return found;
    >
    I am testing this code now. This code appears to allow a long latency
    path. If you have 2 SCHED_FIFO tasks which are both ready to run and
    the kernel is in this (long) free_inode loop, one task will get scheduled
    and if it finishes quickly the other task will have to wait.

    Could you explain again what the problem is when we always allow
    schedule?

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