home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8466 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  3.1 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!klaava!liljeber
  2. From: liljeber@klaava.Helsinki.FI (Mika Pekka Liljeberg)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: shared libs - can everyone be happy with this?
  5. Message-ID: <LILJEBER.92Aug17203359@klaava.Helsinki.FI>
  6. Date: 17 Aug 92 18:33:59 GMT
  7. References: <1992Aug17.144719.1961@crd.ge.com> <1992Aug17.151311.29507@ods.com>
  8. Sender: liljeber@klaava.Helsinki.FI (Mika Pekka Liljeberg)
  9. Organization: Department of Computer Science, University of Helsinki, Finland
  10. Lines: 52
  11. In-Reply-To: david@ods.com's message of 17 Aug 92 15: 13:11 GMT
  12.  
  13. In article <1992Aug17.151311.29507@ods.com> david@ods.com (David Engel) wrote:
  14. > william E Davidsen (davidsen@ariel.crd.GE.COM) wrote:
  15. > : In article <1992Aug17.065450.28834@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
  16. > : 
  17. > : | Boom.  You've just dirtied that page, and it is no longer 
  18. > : | shareable.  So, instead of having > 200K shared between all
  19. > : | of your shells, you have closer to 800K (Who has less than
  20. > : | 4 shells running at a time).  Not a good thing (tm).
  21. > : 
  22. > :   Well, no, actually. Since the new version of the page is still valid
  23. > : for all processes it would still be sharable. And it would not have to
  24. > : be saved somewhere in the unlikely event that it gets paged out, because
  25. > : the unmodified varsion is still perfectly valid.
  26. > 
  27. > No, it wouldn't be shareable.  When a process writes to a shared page,
  28. > it gets its very own copy of it which is no longer shared.  There is a
  29. > term for this that you probably already know, but others may not.  It's
  30. > called Copy-On-Write.
  31.  
  32. I'll admit right away that I'm no expert, but it seems to me that William is
  33. right. The page _could_ still be shared, since all the processes using the
  34. page would be using the same libs. Of course, some kernel support would be
  35. needed: The page fault handler would have to check, if the referenced address
  36. is in library space and if so, fix the reference to point to the correct
  37. place in the library and clear the dirty-bit for that page instead of doing
  38. a Copy On Write. This would also work for static data references, as long as
  39. the data structures didn't change too profoundly.
  40.  
  41. Would this break demand loading, then? I think not. A text page could still
  42. be freed and reloaded on demand. Any library references on it would simply
  43. get relinked, when the path of execution intercepted them.
  44.  
  45. Also, I don't think this would bloat the kernel much at all. It would be a
  46. fairly small addition to the page fault handler (ok, if I'm wrong, sue me).
  47.  
  48. So, what am I missing? I know you have researched this matter thoroughly and
  49. have decided that jump libs are The Way It Should Be Done (and a good way it
  50. is, too). But why not do it this way? (btw, I followed the discussion on the
  51. GCC channel, when it was most heated and I don't recall seeing anything to
  52. prevent this).
  53.  
  54. > David
  55. > -- 
  56. > David Engel                        Optical Data Systems, Inc.
  57. > david@ods.com                      1101 E. Arapaho Road
  58. > (214) 234-6400                     Richardson, TX  75081
  59.  
  60.     Mika
  61. --
  62. Mika Liljeberg            Email:    liljeber@kruuna.Helsinki.FI
  63. Helsinki University            Mika.Liljeberg@Helsinki.FI
  64. Dept. of Computer Science
  65.