On Sunday February 18, markhe@veritas.com wrote:
> Hi Neil, all,
>
> The nfs daemons run holding the global kernel lock. They still hold
> this lock over calls to file_op's read and write.
>
> The file system kernel interface (FSKI) doesn't require the kernel lock
> to be held over these read/write calls. The nfs daemons do not require
> that the reads or writes do not block (would be v silly if they did), so
> they have no guarantee the lock isn't dropped and retaken during
> blocking. ie. they aren't using it as a guard across the calls.
>
> Dropping the kernel lock around read and write in fs/nfsd/vfs.c is a
> _big_ SMP scalability win!
Certainly I would like to not hold the BKL so much, but I'm curious
how much effect it will really have. Do you have any data on the
effect of this change?
Also, I would much rather drop the lock in nfsd_dispatch() and then go
around reclaiming it whereever it was needed.
Subsequently we would drop the lock in nfsd() and make sure sunrpc is
safe.
This would be more work (any volunteers?:-) but I feel that dropping
it in little places like this is a bit unsatisfying.
Thanks for the input,
NeilBrown
[patch deleted]
-
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/
This archive was generated by hypermail 2b29 : Fri Feb 23 2001 - 21:00:26 EST