Messages in this thread Patch in this message | | | Date | Thu, 31 Mar 2005 09:15:04 +0200 | From | Ingo Molnar <> | Subject | Re: 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/
| |