Re: NFS client latencies

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/