Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!oliveb!mipos3!pinkas From: pinkas@hobbit.intel.com (Israel Pinkas ~) Newsgroups: comp.emacs Subject: Re: Does GNU emacs ever use shared libraries? Message-ID: Date: 16 May 89 21:18:51 GMT References: <152@talarian.UUCP> <39999@bbn.COM> Sender: news@mipos3.intel.com Followup-To: comp.unix Distribution: usa Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA Lines: 81 In-reply-to: jr@bbn.com's message of 16 May 89 14:42:30 GMT I am redirecting followups to comp.unix, where this stuff belongs. In article <39999@bbn.COM> jr@bbn.com (John Robinson) writes: > pinkas@hobbit (Israel Pinkas ~) writes: > >SunOS 4.0 executables do not swap text pages by default (-z flag to ld). > >They are released from memory and marked as not present. If needed again, > >they are loaded from the disk image. If the original image is on an NFS > >mounted partition, every page fault results in an NFS access. This hurts > >performance on large processes. > > This depends on your configuration. If your swap device is remote via > ND or NFS, swapping a page results on two network accesses. And ND is > more costly than NFS to boot. Our configuration is a "dataless workstation model". Swap space (anywhere from 16M to 100M) is local. The kernel, and most of the "basic" binaries distributed are local. User directories, /usr/local, etc. are NFS mounted. We run primarily on Suns and uVaxen. With this configuration in mind, my orginal statement(s) makes more sense. > >1) If the file server becomes unavailable (crashes, times out, etc.) the > >page fault can fail and the process can hang. The network is flooded with > >NFS requests, which slows down everybody. > > I don't think you can do much better than this with a diskless node. > To minimize your exposure, your executables and swap area should be > provided by the same server. I don't know whether NFS or ND behaves > worse when the server croaks. No diskless nodes here. We NFS mount user data and our binary distributions (ours, not the Unix ones). > >2) If the image is deleted, everything goes haywire. > > Whoa. My understanding has always been that you can unlink a file, > but its inode stays around until every open FD on it is closed. You > are implying that NFS breaks this behavior? Seems to me that Unix > would have a hard time living with this change. Due to the statelessness of NFS, the inode on the server is not held open. As a result, if workstation A is using a binary, and somebody on workstation B deletes that binary, it is gone. Workstation A starts reporting NFS Stale File Handles. (This also happens if the file is deleted on the server.) I believe (but haven't checked) that the implementations of NFS that we have are OK when another process on A tries to delte the file. How, I am not sure. What we have done is implement a methodology. Instead of removing the file, rename it. (i.e. emacs -> .emacs.orig) The delete it a week later. The point is that hopefully in that week, all NFS references to the file are gone. (We rarely have somebody logged in for a whole week. We discourage it for various reasons, including security.) > >(I didn't think that anybody would > >leave an Emacs process around for more than a week, but guess what?) > > Sho nuff. Do it all the time. One problem I had with GNU Emacs is that on every workstation that I have ever run on, Emacs accrues a lot of CPU time. (Let's not get into an editor war about features/CPU/memory.) After a certain amount of CPU, the kernel renices the process for me. Nasty for interactive processes. After a week, even if I never touch a key, Emacs is dogmeat. (The again, so is xclock.) -Israel Pinkas -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas@cadev4.intel.com