lkml.org 
[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: NFS client latencies

    * Ingo Molnar <mingo@elte.hu> wrote:

    > i think all it needs now is a lock-breaker in the main radix-lookup
    > loop in nfs_scan_lock_dirty(), or a latency-oriented reduction in the
    > npages argument, to make the loop bounded. [...]

    can nfsi->req_lock be dropped within nfs_scan_dirty()? Or does the
    scanning have to restart in that case? My guess would be the scanning
    does not have to be restarted, since we drop the lock after scanning
    anyway, so all it has to take care of is the consistency of the list
    itself, and the fact that the whole index range got scanned in a certain
    point in time.

    Such a lock-breaker was hard before because we had a list 'cursor' which
    could move away while we dropped the lock. But with the radix tree it's
    an 'index position' now, which is much more invariant. The patch below
    attempts this, ontop of your patch - but i'm not sure whether ->req_lock
    is the only lock we hold at that point.

    Ingo

    --- linux/fs/nfs/pagelist.c.orig
    +++ linux/fs/nfs/pagelist.c
    @@ -291,6 +291,7 @@ nfs_scan_lock_dirty(struct nfs_inode *nf
    res++;
    }
    }
    + cond_resched_lock(&nfsi->req_lock);
    }
    out:
    return res;
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/
    \
     
     \ /
      Last update: 2005-04-06 13:31    [W:4.029 / U:0.380 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site