home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!sun-barr!olivea!decwrl!access.usask.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!bstone
- From: bstone@acs.ucalgary.ca (Blake Stone)
- Newsgroups: comp.sys.next.misc
- Subject: Swapfile Compression
- Message-ID: <92Aug29.170741.21491@acs.ucalgary.ca>
- Date: 29 Aug 92 17:07:41 GMT
- Sender: news@acs.ucalgary.ca (USENET News System)
- Distribution: na
- Organization: The University of Calgary, Alberta
- Lines: 35
- Nntp-Posting-Host: acs3.acs.ucalgary.ca
-
- > Uh, I *REALLY* Don't think compress=lzw/packbits/etc. That
- > would be totally retarded, not to mention totally unuseable on
- > an '030 and damn near it on an '040. I would gather compressed
- > = compacted in that the holes in the swapfile are reused more
- > wisely and the paging system tries to keep the swapfile to a
- > minimum ...
-
- Uh, wrong. According to NeXT at NeXTworld Expo the 'swaptimizer'
- would actually compress individual pages. Beta 3.0 releases will
- do this by default ONLY on 8MB RAM machines. Holes in the
- swapfile ARE reused in 2.x. The problem is that pages at the end
- of the swapfile allocated by, say, the Workspace Manager or the
- Window Server keep the swap from being truncated. They need to
- be able to intelligently MOVE pages in the swapfile (logically,
- not necessarily physically). Tough problem and still unsolved in
- 3.0.
-
-
- > This growing rumor is totally unfounded and technically silly
- > IMNSHO.
-
- It actually makes sense since:
-
- 1) A task that is swapping is blocked.
- 2) The Window Server is the most likely task to swap.
- 3) The Window Server is not threaded.
- 4) All NeXT apps block pending replys from the Window Server on a
- regular basis.
-
- What NeXT really needs to do is thread the window server!
- (Assuming that only one thread in a task is blocked during
- swapping... which could be patently untrue. Anybody know for
- sure?).
-
- Blake
-