On Wed, Dec 05, 2012 at 08:01:13AM -0800, Chuck Silvers wrote:
> this seems to be trying to work around our current limitation that all writes
> to a given vnode are serialized, is that right?
It is partially. Another aspect is CPU cache trashing, by processing
the same socket by manu CPUs we load and eventually write the
same variables in different CPUs cache, and this could well make processing
slower than a pure sequencial processing.
> eventually we'd like to
> improve things such that I/O to non-overlapping ranges of the file can be
> processed in parallel.
nice goal, but it doesn't look easy, and I guess you'll still need a lock
at last to gain exclusive ownerchip of a range. So there will still
be some lock contention. This, with the CPU cache issue mentionned
above, may still not make a multithread nfsd servicing a single socket
faster than a single nfsd thread.
> this change appears to help in the context of the
> current limitation, but it sounds like the opposite direction for what we'd
> like to do in the long run. it would be better if we could find some way
> improve things now that won't make life harder for ourselves later.
We still want to process UDP sockets in parallel, so the code to do things
in multiple threads is still there, and will stay. So going back to a
multithreaded processing for connected sockets shouldn't be hard in
the future, if we want to.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
