Date: Tue, 03 Jun 2003 00:14:02 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@freebsd.org Subject: Re: Making a dynamically-linked root Message-ID: <3EDC4ABA.F923A9C8@mindspring.com> References: <20030602171942.GA87863@roark.gnf.org> <20030602202947.GE87863@roark.gnf.org> <xzpznl02nry.fsf@flood.ping.uio.no> <200306022125.h52LPhhc002291@apollo.backplane.com> <200306022224.h52MOIwj002729@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > Ah, but you are still waiting on 'disk I/O'... it just happens to be > *network* disk I/O, so it doesn't matter if it's in the server's > cache or not. > > A lot of the delay is due to the client program stalling until the page > is faulted in over the network (and not doing any other work in the mean > time), then running for a few cycles and stalling again waiting for the > next random page to be faulted in. Yes. This is still incredibly frustrating; the same stall happens in N:M and N:1 threading models, whenever a page fault happens, since it stalls the kernel thread where the fault occurred, meaning it can't run other user space code while it's waiting for the fault to be satisfied. It would be very useful if other code could proceed while waiting for the fault; particularly when it's a decriptor with non-blocking I/O set on it (you'd expect the fault to proceed in the background, and make the data be there for when you retry the read). > Another big issue with the diskless code is the path cache. Whenever > a shell script runs a program using a relative path (like 'ls' instead of > '/bin/ls'), it tries to stat the program file for each path element in > the path. With a local disk the local system's name cache is coherent > and these operations are nearly instantanious. Over NFS, however, a > lot of retesting of the same paths are done over the network over and > over again, leading to a massive perceived slow down, and even retesting > a good path like /bin/sh often generates NFS traffic looking up "/bin/sh" > over and over again. The effects of this should be much less than you imply, as long as you are hitting the same terminal object name several times (that's why the name cache support negative caching). > For example, if in one window you start a tcpdump and monitor port > 2049 (typically nfsd), and in another window you run /bin/sh, you > will see at least 3 NFS lookups. If you exit the shell and run it again > you will see the same 3 NFS lookups again. And again, and again. Then the negative caching is broken, and needs to be fixed. Actually, there's probably some extra wire traffic happening, if you aren't using NFSv3, which caches VOP_ACCESS() calls when it can. Probably the name cache code should be done higher up in the VFS layer, so that it's mostly operating no local nfsnode data, or just the vnode; only it's not. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EDC4ABA.F923A9C8>