f31dba4c5d
if a single process is performing a large number of requests (in this case writing a large file). The writing process could monopolise the recieve lock and prevent any other processes from recieving their replies. It also adds a new sysctl variable 'vfs.nfs.dwrite' which controls the behaviour which originally pointed out the problem. When a process writes to a file over NFS, it usually arranges for another process (the 'iod') to perform the request. If no iods are available, then it turns the write into a 'delayed write' which is later picked up by the next iod to do a write request for that file. This can cause that particular iod to do a disproportionate number of requests from a single process which can harm performance on some NFS servers. The alternative is to perform the write synchronously in the context of the original writing process if no iod is avaiable for asynchronous writing. The 'delayed write' behaviour is selected when vfs.nfs.dwrite=1 and the non-delayed behaviour is selected when vfs.nfs.dwrite=0. The default is vfs.nfs.dwrite=1; if many people tell me that performance is better if vfs.nfs.dwrite=0 then I will change the default. Submitted by: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> |
||
---|---|---|
.. | ||
alpha | ||
amd64 | ||
compat/linux | ||
compile | ||
conf | ||
ddb | ||
dev | ||
fs | ||
geom | ||
gnu | ||
i386 | ||
isa | ||
isofs/cd9660 | ||
kern | ||
libkern | ||
miscfs | ||
modules | ||
msdosfs | ||
net | ||
netatalk | ||
netinet | ||
netipx | ||
netkey | ||
netns | ||
nfs | ||
nfsclient | ||
nfsserver | ||
pc98 | ||
pccard | ||
pci | ||
powerpc/include | ||
rpc | ||
scsi | ||
sys | ||
tools | ||
ufs | ||
vm | ||
Makefile |