home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8532 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  2.4 KB
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ariel!davidsen
  2. From: davidsen@ariel.crd.GE.COM (william E Davidsen)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: shared libs - can everyone be happy with this?
  5. Message-ID: <1992Aug18.125901.28955@crd.ge.com>
  6. Date: 18 Aug 92 12:59:01 GMT
  7. References: <1992Aug17.144719.1961@crd.ge.com> <1992Aug17.151311.29507@ods.com> <NOP.92Aug17135014@theory.Mankato.MSUS.EDU>
  8. Sender: usenet@crd.ge.com (Required for NNTP)
  9. Reply-To: davidsen@crd.ge.com (bill davidsen)
  10. Organization: GE Corporate R&D Center, Schenectady NY
  11. Lines: 41
  12. Nntp-Posting-Host: ariel.crd.ge.com
  13.  
  14. In article <NOP.92Aug17135014@theory.Mankato.MSUS.EDU>, nop@theory.Mankato.MSUS.EDU (Jay A. Carlson) writes:
  15.  
  16. | I think that William and I were thinking in a more theoretical slant.
  17. | Yes, the kernel would give each process its own copy if this was done
  18. | without guile.  
  19.  
  20.   Exactly so. We need to write the page in such a way that the kernel
  21. doesn't notice. Hum, I've used kernels that did that, but it wasn't a
  22. feature.
  23.  
  24. | A brute force technique would be to include a kernel function that
  25. | would do the necessary patch and then restore the previous
  26. | dirty-status of the page.
  27.  
  28.   Or, as you implied earlier, not effect the status at all. Since these
  29. are shared code segs, they better be clean.
  30.  
  31. | Note that with processes sharing the same text, there is even less
  32. | overhead, since the patch only happens once per call point per shared
  33. | image instead of once per call point per process.
  34.  
  35.   I had completely missed this. The overhead of a single fixup is shared
  36. between all processes running the image. That is a feature of a runtime
  37. loader, as well.
  38.  
  39. | I'm not sure that all this trouble is worth it.  Does anyone have any
  40. | hard data on the performance loss of jump tables?
  41.  
  42.   That's very hard to get, since the overhead is dependent to some
  43. degree on program behavior and system load. If the jump table stays in
  44. memory due to usage, the overhead is small. If the call to the jump
  45. table results in a page fault, the realtime goes up, and the system
  46. overhead may or may not be reported back to the process. Up to a certain
  47. point load help keep the JT in memory, after which it starts to force
  48. other stuff out, and the memory used by the jump table(s) starts to
  49. hurt. This seems likely only in a machine with minimal memory for its
  50. load.
  51.  
  52. -- 
  53. bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
  54.     I admit that when I was in school I wrote COBOL. But I didn't compile.
  55.