* Ingo Molnar <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
